Я исхожу из описанного кейса, и додумывать не буду. Будут другие вводные, может быть поменяю мнение.
Что-то мне подсказывает, нормальный исход заключался бы в том, что оба поговорили бы и один рассказал что нужно для фронта, второй бы написал правильные статусы на бекенде для разных ситуаций.
Я работал и с хорошими бекендерами и с аналогом «Л». И симптомы похожи.
При работе с хорошим бекендером у меня ни разу не закралась мысль, что будет проще самому написать нужную реализацию, всегда все можно было объяснить и договорится о лучшем дизайне api как с точки зрения стандартов проектирования так и работы с ним на фронте.
Как я понимаю, он не остался бы антигероем до конца, если бы обсудил эти изменения.
Был аналогичный опыт с другим «Л». Только, когда «Л» перевели на другой проект и там не выдержал фронтендер — уволился, передо мной извинились. Я понимаю автора, это очень выматывает каждый день работать с человеком который не хочет слушать и искать компромиссы.
И фронтендеры тут оказываются под ударом, т.к. руководство и клиенты никогда не увидят бекенда. А хороший дом на кривом фундаменте не построить. В какой-то момент замечаешь, что больше 50% времени борешься с проблемами которых можно было бы избежать при нормальном api или которых даже не пришлось бы решать, т.к. должна решаться на уровне бекенда и запросов к БД.
В некотором роде 10x это маркетинговая стратегия инженера. Засветиться как можно чаще в решении как можно большего числа вопросов и стать значимым для большего числа людей.
Это довольно распространенная стратегия в корпоративном сегменте и медиа и в друших сферах
А должен?
Ну как по мне контекст тоже влияет.
И 10x это наблюдаемая кем-то со стороны производительность. Тим лид будет видеть все закрываемые задачи, руководитель будет видеть один еще не завершенный проект.
Поясню, что я исхожу из предположения что физически 10x успевает столько же сколько и 1x. Но в силу того что черпает опыт из разных направлений, проектов и задач, то может некоторые вопросы решать более эффективно и быстрее чем 1x.
Описали качества хорошего инженера. К ним можно стремиться. Но 10x и 1x это про производительность, контекст и наблюдателя.
— Есть области где каждый мелкий результат на виду. Микросервисы, фронтенд. Видимого результата больше.
— Есть сферы где выигрывает многозадачность и умение быстро переключаться. Если находить решение проблемы теми средствами что есть и в те сроки что есть, то решение проблемы — это уже видимый результат, но до готового продукта все равно остается год.
Для меня разница между 10x и 1x — умение быстро переключаться между контекстами и проектами.
С точки зрения бизнеса 10x — это хорошо, т.к. решает насущные проблемы, с точки зрения продукта — не очень, т.к. конкретный продукт может медленнее двигаться к результату из-за постоянных временных решений.
Мое представление (по крайней мере к этому наблюдается тренд):
10x — agile инженер
1x — waterfall инженер
Вообще, команда — это часовой механизм. Каждый в ней шестеренка разного размера с разным количеством зубьев и каждая шестеренка по разному взаимодействует с соседней. А по описанию, команда похожа на поршни ДВС, все хотят чтобы у них мотор ревел и все неслись в светлое будущее, но если не видно шестеренок, значит что-то упущено.
Люди как правило не плохие. Работают потому, что хотят работать. И вообще, стремятся быть хорошими. Может проблемный сотрудник пытается заменить недостающие шестеренки в команде, может считает что это поведение — то, что от него ждут. Бывает так, что на собеседовании ему пообещали одно, а потом удивляются, почему он не поршнем вкалывает, а идеи генерирует, он то уверен что делает полезное дело.
Надо честно говорить, что ожидаете от сотрудника и что кажется странным в его поведении. И тогда не будет таких проблем. А проверка эффективности — это как синтетические тесты, вроде провел, но все равно не веришь.
Но самое главное, что отношения легко изменяются из хороших в плохие, но очень сложно из плохих в хорошие. Точка невозврата уже пройдена в тот момент когда команда выразила свое нежелание работать с «проблемным» сотрудником.
Все остальные действия — припарки. С одной стороны попытка руководства замять инцидент и вернуть все как было, а со стороны управляющего попытка избавится от проблем в лице сотрудника.
Такое поведение у человека не в один день проявилось, просто все молчали, пока не надоело. А как надоело начали придумывать отмазки типа работает медленнее, не как все и т.п.
Жонглируя ножами на скорости более 200 км/ч — не знаю. Я другой вывод делаю. Что даже утонувший титаник не помешал развиваться кораблестроению. Разве что конкорды перестали летать после аварии, но там скорее всего были очень «дорогие» жизни :)
Вообще, я совсем про другое, а не про вероятность аварии на конкретном средстве передвижения.
Тогда уж для честности надо выяснять эти показатели для одинаковых скоростей.
Какой шанс аварии и выжить в ней, если оба транспортных средства движутся с одной скоростью около 200 км/ч — 300 км/ч
Главная проблема статьи в том, что автор думает, что заголовок многое объясняет.
Я понимаю, что автор находится в своем контексте и окружен этой проблемой, которую описывает в статье. А поэтому многие вещи считает понятными и не требующими объяснения. А выбор хабов и тегов, видимо, должны сделать все остальное.
Но есть огромное количество людей для которых тема далека от повседневности. Им нужны вводные данные или может быть тема ТУ вовсе не интересна
Я не знаю как эта статья попала мне в выдачу, но т.к. попала, то и оцениваю из своего контекста: постановка задачи не ясна, область решаемых задач не определена, заголовок ни о чем.
Человек, который будет искать решение подобной задачи никогда не найдет этой статьи, и не подумает ее открыть в поисках решения. Я надеюсь автор исправится, поправит статью и десятки или сотни людей, для которых тема актуальна, смогут использовать решение из второй части на практике и дадут автору фидбек.
Ваши данные стоят где-то 1-5% стоимости товаров что вы покупаете (размер скидок по картам лояльности или кешбекам). Предположим, что это 5 рублей в день при тратах 500 рублей в день. Это стоимость данных для самого магазина (не считая системы сбора, хранения и анализа).
Вот тут и вырисовывается рынок, когда мы продадим данные миллиона пользователей по 1 рублю в день
Вот теперь ясно, что вы говорите о том в чем совершенно не разбираетесь.
Вам конкретные цитаты или сами сможете книги прочесть? Лень подборку делать. Выберите что нибудь удовлетворяющее вашим критериям авторитетности источника: store.artlebedev.ru/books/design-theory
Нашел вашу цитату: «вы слишком безграмотны чтобы учитывать ваше мнение.» :)
Есть армия граф. дизайнеров есть сотни книг по графическому дизайну. Вопрос компенсаций — это вопрос опыта тысячи профессионалов. И в противовес появилось ваше мнение. Но я все равно выберу мнение профессионалов накопленное десятилетиями.
То, что вам кажется лучшим — ваше дело. Но есть не просто однократные исследования, но и накопленный профессиональный опыт в графическом дизайне, что для большинства так лучше. Большинство и выигрывает, а часть просто не замечает.
А почему вы убеждаете кого-то терять деньги (проигрывая в конкурентной борьбе за пользователей), потому что вам нравится по другому я опять же не понимаю.
Вам же никто не запрещает не покупать то что не нравится
А я не вижу проблемы, те кто не заметит продолжат спокойно жить. А те кто заметит не почувствует дискомфорт. И те кто замечают предпочтут более продуманный дизайн.
Это называется воспитание вкуса.
— Чтобы понимать живопись, нужно учиться ее понимать
— Чтобы видеть в коде паттерны программирования нужно их изучать
— Чтобы писать «правильный» код нужно учиться его распознавать и писать
Логика, о том что если я не замечаю, то этого нет и не нужно — выглядит странной
Как-то сталкивался с конкурсом на криптобирже по торговле специально выпущенными псевдо активами: wsoc.io.
Вот там торговые роботы — легальные участники конкурса. А махинации должны были блокироваться набором правил в умных ассетах (сами активы).
А я помню, как в давние времена, когда подрабатывал эникейщиком, в одной небольшой компании архив писем theBat находился на общем сетевом диске, потому, что нужно было шарить почту, а сервера дорогие.
И в один прекрасный день архив достиг 4 гигов, а диск был Windows машине с файловой системой fat32. И тут вся почта компании умерла…
Это к тому, что у каждой задачи свое решение. И хорошо, если ваша задача может решаться одним инструментом 20 лет
Что-то мне подсказывает, нормальный исход заключался бы в том, что оба поговорили бы и один рассказал что нужно для фронта, второй бы написал правильные статусы на бекенде для разных ситуаций.
Я работал и с хорошими бекендерами и с аналогом «Л». И симптомы похожи.
При работе с хорошим бекендером у меня ни разу не закралась мысль, что будет проще самому написать нужную реализацию, всегда все можно было объяснить и договорится о лучшем дизайне api как с точки зрения стандартов проектирования так и работы с ним на фронте.
Был аналогичный опыт с другим «Л». Только, когда «Л» перевели на другой проект и там не выдержал фронтендер — уволился, передо мной извинились. Я понимаю автора, это очень выматывает каждый день работать с человеком который не хочет слушать и искать компромиссы.
И фронтендеры тут оказываются под ударом, т.к. руководство и клиенты никогда не увидят бекенда. А хороший дом на кривом фундаменте не построить. В какой-то момент замечаешь, что больше 50% времени борешься с проблемами которых можно было бы избежать при нормальном api или которых даже не пришлось бы решать, т.к. должна решаться на уровне бекенда и запросов к БД.
Это довольно распространенная стратегия в корпоративном сегменте и медиа и в друших сферах
Ну как по мне контекст тоже влияет.
И 10x это наблюдаемая кем-то со стороны производительность. Тим лид будет видеть все закрываемые задачи, руководитель будет видеть один еще не завершенный проект.
Поясню, что я исхожу из предположения что физически 10x успевает столько же сколько и 1x. Но в силу того что черпает опыт из разных направлений, проектов и задач, то может некоторые вопросы решать более эффективно и быстрее чем 1x.
— Есть области где каждый мелкий результат на виду. Микросервисы, фронтенд. Видимого результата больше.
— Есть сферы где выигрывает многозадачность и умение быстро переключаться. Если находить решение проблемы теми средствами что есть и в те сроки что есть, то решение проблемы — это уже видимый результат, но до готового продукта все равно остается год.
Для меня разница между 10x и 1x — умение быстро переключаться между контекстами и проектами.
С точки зрения бизнеса 10x — это хорошо, т.к. решает насущные проблемы, с точки зрения продукта — не очень, т.к. конкретный продукт может медленнее двигаться к результату из-за постоянных временных решений.
Мое представление (по крайней мере к этому наблюдается тренд):
10x — agile инженер
1x — waterfall инженер
Люди как правило не плохие. Работают потому, что хотят работать. И вообще, стремятся быть хорошими. Может проблемный сотрудник пытается заменить недостающие шестеренки в команде, может считает что это поведение — то, что от него ждут. Бывает так, что на собеседовании ему пообещали одно, а потом удивляются, почему он не поршнем вкалывает, а идеи генерирует, он то уверен что делает полезное дело.
Надо честно говорить, что ожидаете от сотрудника и что кажется странным в его поведении. И тогда не будет таких проблем. А проверка эффективности — это как синтетические тесты, вроде провел, но все равно не веришь.
Но самое главное, что отношения легко изменяются из хороших в плохие, но очень сложно из плохих в хорошие. Точка невозврата уже пройдена в тот момент когда команда выразила свое нежелание работать с «проблемным» сотрудником.
Все остальные действия — припарки. С одной стороны попытка руководства замять инцидент и вернуть все как было, а со стороны управляющего попытка избавится от проблем в лице сотрудника.
Такое поведение у человека не в один день проявилось, просто все молчали, пока не надоело. А как надоело начали придумывать отмазки типа работает медленнее, не как все и т.п.
Тогда уж для честности надо выяснять эти показатели для одинаковых скоростей.
Какой шанс аварии и выжить в ней, если оба транспортных средства движутся с одной скоростью около 200 км/ч — 300 км/ч
Так, как-то честнее сравнение
— За год погиб один человек при использовании реактивного ранца
— За один год при ДТП в России погибло 16,9 тыс человек
Статистика говорит, что смерть у людей не является определяющим фактором при выборе средства передвижения
Я понимаю, что автор находится в своем контексте и окружен этой проблемой, которую описывает в статье. А поэтому многие вещи считает понятными и не требующими объяснения. А выбор хабов и тегов, видимо, должны сделать все остальное.
Но есть огромное количество людей для которых тема далека от повседневности. Им нужны вводные данные или может быть тема ТУ вовсе не интересна
Я не знаю как эта статья попала мне в выдачу, но т.к. попала, то и оцениваю из своего контекста: постановка задачи не ясна, область решаемых задач не определена, заголовок ни о чем.
Человек, который будет искать решение подобной задачи никогда не найдет этой статьи, и не подумает ее открыть в поисках решения. Я надеюсь автор исправится, поправит статью и десятки или сотни людей, для которых тема актуальна, смогут использовать решение из второй части на практике и дадут автору фидбек.
Ваши данные стоят где-то 1-5% стоимости товаров что вы покупаете (размер скидок по картам лояльности или кешбекам). Предположим, что это 5 рублей в день при тратах 500 рублей в день. Это стоимость данных для самого магазина (не считая системы сбора, хранения и анализа).
Вот тут и вырисовывается рынок, когда мы продадим данные миллиона пользователей по 1 рублю в день
А сами свои данные вы продаете в программах лояльности — когда в магазине анкету заполняете, чтобы скидки и кешбеки получать.
А что бы превратить данные множества людей в статистику нужно создать программные комплексы по сбору, хранению и анализу этих данных.
Как только сможете дать Амазону или Воллмарту статистику, получите от них деньги или может на бартер договоритесь
Вам конкретные цитаты или сами сможете книги прочесть? Лень подборку делать. Выберите что нибудь удовлетворяющее вашим критериям авторитетности источника: store.artlebedev.ru/books/design-theory
Нашел вашу цитату: «вы слишком безграмотны чтобы учитывать ваше мнение.» :)
Есть армия граф. дизайнеров есть сотни книг по графическому дизайну. Вопрос компенсаций — это вопрос опыта тысячи профессионалов. И в противовес появилось ваше мнение. Но я все равно выберу мнение профессионалов накопленное десятилетиями.
То, что вам кажется лучшим — ваше дело. Но есть не просто однократные исследования, но и накопленный профессиональный опыт в графическом дизайне, что для большинства так лучше. Большинство и выигрывает, а часть просто не замечает.
А почему вы убеждаете кого-то терять деньги (проигрывая в конкурентной борьбе за пользователей), потому что вам нравится по другому я опять же не понимаю.
Вам же никто не запрещает не покупать то что не нравится
Это называется воспитание вкуса.
— Чтобы понимать живопись, нужно учиться ее понимать
— Чтобы видеть в коде паттерны программирования нужно их изучать
— Чтобы писать «правильный» код нужно учиться его распознавать и писать
Логика, о том что если я не замечаю, то этого нет и не нужно — выглядит странной
Но, возможно, зарплата уборщика в SpaceX будет побольше чем в Роскосмосе.
Вот там торговые роботы — легальные участники конкурса. А махинации должны были блокироваться набором правил в умных ассетах (сами активы).
Но и там без накруток не обошлось
И в один прекрасный день архив достиг 4 гигов, а диск был Windows машине с файловой системой fat32. И тут вся почта компании умерла…
Это к тому, что у каждой задачи свое решение. И хорошо, если ваша задача может решаться одним инструментом 20 лет
Слушал по радио одного психолога и понравилась мысль: «здоровый человек книгу писать не будет, ему жить интереснее».