Я на этом завалился лет 5 назад. Я когда-то давно занимался олимпиадным программированием и думал с задачами проблем не будет. Но там была откровенная жесть, кони с доской отдыхают. Я потом похожие задачи находил на олимпиаде уровня чемпионата ЮАР, а это уже какой-никакой уровень, без тренировки и подготовки такое не решить. Я гарантирую, только человек который достаточно активно решает олимпиадные задачи мог бы это решить за отведённое время.
Пришёл к выводу, что варианта два
Повезло и задачи простые
Задачи не решать, но отправить что-то, что пройдёт хотя-бы 10% тестов. 4 задачи дадут приемлемую сумму баллов.
>Посчитайте снова. Ваш расчёт должен дать коэффициент использования 10%, а не 1%. И такая ошибка сильно повлияет на выбор технологии.
В моем расчете нет никакого коэффициента использования. Есть пиковая нагрузка, для которой нужно 300 машин, которая бывает 15 дней в году. Что изменится если она бывает 100 дней в году? Только то, что облако станет менее эффективным с точки зрения денег. А если 300 машин надо 365 дней в году и никаких всплесков нет, то облако вообще пролетает. Предсказывать всплески на этапе выбора архитектуры так себе занятие.
>Это тоже искажающее картину соображение. Если бизнесу что-то реально надо - они найдут сервера за один день (ну поусть неделю).
Бизнес это не человек, ему ничего не надо и он ничего не чувствует. Как по вашему "ему надо" должно работать? Железного сервера нужной комплектации от нужного производителя может не быть в России или в вашем городе. Можно закупать что есть и получить зоопарк железа, каждое с своими особенностями. А еще договор на поставку нужно с юристом обсудить, а затем в фин. дирктором. А он в отпуске. А затем менеджер со стороны поставщика ушел в отпуск или заболел. А затем поставщик не ту конфигурацию прислал или не те реквизиты выслал. И пошло поехало.
Пусть менеджер проекта сам закупает технику без лишнего контроля и процедур? И вот у нас откаты менеджеру от поставщиков и полный бардак с тем, кто кому сколько должен, какой товар уже пришел, какой к возврату, а какой получили, где все это находится и в каком состоянии.
И пример закупок из практики - купить и вернуть полотенцесушитель за 20 тыр. - 50 писем поставщику и обратно, пара рабочих дней времени. И это ИП покупает для себя, без процессов и контроля. Боюсь реальность закупок чего-то сложнее еды в магазине или книги на озоне вас может очень разочаровать.
>> А отдать лишнее железо производителю не получится
>И это не проблема.
Предлагаете все тренировать GPT-3 на свободных мощностях? Вот только как инициатор этого проекта вообще узнает о том, что есть свободные мощности? Сколько людей и ИТ систем должно слажено работать вместе, чтобы появилась таблица с свободными серверами, чтобы к ним был доступ у кого надо, чтобы на них можно было запускать GPT-3 и так далее. Все можно, но это не просто так дается.
>Так же и вы - выделяйте виртуалку и нарезайте ресурсы кому нужно.
Это очень упрощенное представление о правах доступа и сценариях с ними. Дело не в виртуалках совсем.
>Я вам не подскажу конкретные инструменты такого плана, но я очень сильно сомневаюсь в том, что их нет для обычных серверов, но есть исключительно для облаков.
Есть конечно. Для каждой задачи есть какой-то отдельный тул, который ее решает. Связывать и настраивать все это для совместной работы - фул тайм работа для нескольких, далеко не дешевых, человек.
Например, взяли вместо AWS Systems Manager альтернативу, которая на самом деле даже круче - RunDeck. А еще у нас есть Active Directory где юзеры живут. И в RunDeck тоже есть юзеры, с какими-то правами на запуск тех или иных скриптов. И вот кто-то сидит и пилит интеграцию Active Directory <-> RunDeck чтобы из AD можно было рулить тем, кто что может и не может делать.
Или хотим логи - подняли ELK, интегрировали его с AD. Но как теперь разделить права юзеров, кто может видеть логи проекта А, а кто нет? И опять кто-то сидит и пилит интеграцию. Можно забить и в каждый проект свой приватный ELK развернуть. Теперь у вас N источников проблем с обновлением софта и починкой сломавшихся индексов.
Бекапы БД, ну да, есть open source тулы, но их надо настроить, а они еще могут ломаться. А затем нужно права доступа для бекапов настроить. И вот опять AD и интеграция. И так далее до бесконечности.
Понятно, что по среднему никто не берет. Поэтому если для средней нагрузки нужно 30 машин, то вы возьмете 300, чтобы выдержать прыжок в 10 раз. Мы тут считаем, что архитектура хороша и 300 машин действительно нужны.
В облаке вы 350 дней в году используете 30 машин, а 15 дней в году 300. В своем дата центре вы 365 дней в году используете 300 машин на 1% в среднем. Вот в такой ситуации и возникает экономия, а serverless упрощает масштабирование, но имеет свои нюансы.
Есть другие нюансы. В большой организации вы можете ждать сервер по полгода и больше, пока отдел закупок тендер сделает, пока привезут. Если та же организация использует облако, то вы просто заказываете сервер. С другой стороны компания где я сейчас работаю платит AWS миллионы $ в год за железо, которое никому не нужно. С третьей стороны, найти и отдать это железо AWS задача на несколько дней, что регулярно происходит. А отдать лишнее железо производителю не получится. И это лишнее железо, скорее всего, будет привязано к конкретному отделу/команде, а сделать так, чтобы лишнее железо можно было найти и переместить из отдела в отдел это та еще организационная задача.
Также IAM - то есть возможно управлять доступом. В облаке это встроено и работает на любом масштабе, будь то 10 или 10 000 разработчиков. С своим железом и в большой компании вы будете иметь отдел админов, которые будут пилить правила контроля доступа. Обыденные штуки, вроде перешел человек из команды в команду и ему нужны доступы, могут стать целой задачей, с тикетами, менеджерами, админами-исполнителями.
Свое железо - хорошо, облако - тоже хорошо. Просто есть нюансы где одно и другое работает лучше или хуже. Я сначала мигрировал свой небольшой бизнес из AWS на bare metal в OVH и сэкономил несколько тысяч USD в месяц. А сейчас думаю над обратной миграцией, потому что подрос и хочется IAM, ECS, Secrets Manager, Systems Manager и RDS. Делать все это руками на своем железе очень долго и дорого.
Как любой уважающий себя миллионер я знаю, что хранить деньги в долларах это глупо. И знаю я это уже очень давно, потому что ставки по депозитам уже лет 10 или даже больше находятся районе 0%. Поэтому я храню деньги в облигациях, акциях и недвижимости. Эти инструменты с сохранением и преумножением богатства справляются довольно неплохо, особенно золото, недвижимости и бонды.
Наличные не были инструментом сохранения денег. Во всяком случае с конца 20 века и до наших дней.
Отрицательные ставки и вертолетные деньги были до ковида. Кейнсианство вам в помощь, там деньги этот даже не товар, э нечто вроде сигнальной системы, как нейромедиатор в организме. И потому печатать их можно и нужно для поддержания нормального уровня функционирования экономики.
>сейчас эти напечатанные деньги особо у людей не задерживаются, так как они потеряли свой основной источник дохода и вынуждены их сразу потратить.
Разве это плохо? Копить деньги хорошо?
> А там, по отработанным каналам, денежки возвращаются обратно к хозяевам ))
Разве это плохо? Хозяевам же плевать на бумагу, они ее сами печатают и от того, что к ним она вернулась не холодно и не жарко. Разве не так?
>Поскольку крупнейшие владельцы валюты в мировых финансовых центрах заинтересованы именно в росте своего капитала, т.е в повышении цены денег, а значит - в увеличении спроса на них и росте кредитной ставки. Поэтому они создают дефицит, максимально снижают предложение денег на валютных рынках.
Поэтому они печатают деньги и ставки у них отрицательные?
Касательно первого анекдота - люди голодные потому что ресурсы неправильно распределяются, а не потому, что денег напечатать забыли. А модели вроде капитализма или социализма это алгоритмы призванные обеспечить распределение ресурсов. Работают так себе, но это лучшее, что у нас есть.
Если append fsync always то разница будет только на чтении, запись может быть даже медленне чем в БД. У Redis есть ещё кластер, можно смириться с возможной потерей данных, можно организоваться свой WAL на уровне app server. Вариантов много, зависит от профиля нагрузки. Основная идея в том, чтобы использовать очень быстрый, специализированный storage, который позволит пики проходить, не упираясь в БД.
У вас пиковая нагрузка такова, что вам нужно 300 машин. Но 99% времени вам хватит 30. Так и получается экономия на serverless - за счёт автомасштабирования. Можно его сделать на основе API облака и пачки костылей, но работать будет хуже и поддержка будет дорогой.
Это единственный кейс где serverless рулит, если система под него заточена. Но на практике скачки нагрузки в десятки раз именно на базу редко где встретишь. А там где они есть можно пошаманить и данные хранить в Redis, а писать в БД пачками.
Речь же о том, что вы такие идеи генерите регулярно. Нужно всего-то придумать что-то, что можно сделать самому без инвест фонда и озолотиться. Если же все идеи требуют обязательно миллионов usd инвестиций и вы не знаете откуда их взять, то 99.9% это не идеи, а сказки и мечты.
Ваш пример это пример хорошего рац. предложения. Если вы активно в создании и внедрении участвовали, то точно достойны хорошей премии. Но даже если премии нет, то на эксплуатацию эта ситуация не тянет. Просто рабочий эпизод.
Пропорциональное участие в прибыли предполагает пропорциональное участие в убытках. Поэтому покупайте акции и наслаждайтесь результатом своего труда. Боюсь лучше варианта не существует.
>Но этот вариант не сказать чтоб прям идеален был, так как слишком слабая связь между твоей старательностью и выхлопом от всей корпорации.
В том-то и проблема, индивидуальный вклад в выхлоп посчитать нереально. Поэтому и существую привычные формы отношений - продажа продуктивного времени (зп) или продажа конкретного результата (фикс, сдельная оплата).
>Потому по-настоящему горячий энтузиазм может быть только в стартапах среди тех работников, кому принадлежит солидный процент от компании.
Это миф из фильмов и корпоративной мифологии. Никто не будет рвать попу ради призрачного шанса через 5 лет разбогатеть. Будут работать как обычно, но говорить о 80 часовой рабочей неделе. Основатель будет это миф будет культивировать, он помогает увеличить стоимость компании. Можете посмотреть на обсуждения работы в стартапах на hacker news, там видно реальное отношение.
>Одно дело если я сумел очень быстро найти и поправить сложный баг и дальше отдыхаю часок
Думаю с этим никто не будет спорить. Речь о ситуациях когда поправил баг и отдыхаю остаток рабочей недели. Реальная история - разработчик едет на машине из Питера в Крым, ноутбук открыт и он типа работает, трекает время. Жена на заднем сидении тыкает в кнопки, чтобы трекер не ругался. Ну а что? Он же отлично поработал на прошлой неделе, он же 10х программист, а злой капиталист его эксплуатирует, так что пусть платит.
История про «надо доверять команде» не работает так, как обычно говорят. Доверять гражданам надо, но и полицию иметь следует. То есть нужны методы контроля и они будут нормальным людям мешать. И будут создавать серые зоны, типа попить чаю час или два после фикса бага. И эти зоны будут источником конфликта, так как у всех своё понятие о рамках приличия. Но это не значит, что работодатели говнюки или сотрудники мудаки.
Эта ситуация и есть обман. Вы продаёте продуктивное время, не идеи, не результат работы, а именно время. Хотите продавать результат, заключаете фикс. контракт и доставляете результат, нет проблем. Но отношения сотрудник-работодатель подразумевают исполнение обязанностей в течение времени.
Непонятно как считать прибыль от идеи, если придумал Вася, сделал Петя, продаёт Маша, а рынок растёт/падает сам собой? А если идея провалилась, то надо депримировать? И в конце концов - если вы такие золотые идеи генерируете, то почему сами не реализуете и не получите свои 100 окладов с рынка? Пока получается не очень красивая концепция - меня несправедливо эксплуатируют, поэтому я не буду соблюдать договоренности (исполнение обязанностей в течение времени). Можно было бы в это поверит, но у нас рынок кандидатов, о какой эксплуатации тут вообще может идти речь?
Вы попробуйте руководить командой удаленщиков человек в 10-20. Я это делаю последние 10 лет. Мой опыт - при активном найме за 6 месяцев гарантировано будет хотя бы один персонаж, который левачит. Ещё найдутся люди, которые просто пинают балду. Очень часто люди на удаленке понимают, что работать 8 часов в день как-то лениво. Я бы с удовольствием покупал результат и платил фикс по факту выполненных работ. Но так не хотят, обычно хотят зп, а это продажа продуктивного времени. Если покупал 8 часов, а продают 4 - это обман, как не крути. Устал писать код, можно делать ревью, улучшать документацию, участвовать в митинге, обучаться и так далее. Далеко не все задачи программиста на самом деле требуют мега сосредоточенности.
Трекеры это необходимое зло. Только очень стабильная команда может без них обойтись. А если есть хотя бы средняя текучка (работают 2-4 года) и размер команды (5-15 человек) и не дай боже рост, то вы быстро наберёте очень интересных, дорогих и неэффективных персонажей.
В мире удаленки гораздо проще и честнее оплачивать фактически отработанные часы. Не нравится продуктивность/час - расстаётесь. А если результата нет, но и часов нет, то все ясно и нет проблем.
>Вообще для меня программирование — это уже давно постоянная коммуникация.
Половину qsort изобрёл один напарник, а вторую другой, про это речь? В 15м веке было парное рисование картин. Только работало оно гораздо разумнее. Подмастерья рисовали неважные куски по эскизам мастера. И несложно увидеть, что это ускоряет дело. А как дело ускорит обмен данными со скоростью пару килобайт в минуту и кучей ошибок в канале непонятно совершенно.
>И вам изначально назначают зарплату, исходя из оценки вашей продуктивности. И делают переоценку каждый год, на основе этой продуктивности.
Зп зависит не от продуктивности, а от баланса спроса и предложения. Самый сильный предиктор ожидаемой зп - возраст, а не способности, реальные или предполагаемые, кандидата. Мне жат ситуация не нравится, но так уж рынок устроен.
Если разработчик работает на 2х работах, то его продуктивность на каждой это далеко не 50%, скорее 20%. Переключение контекста между задачами стоят очень дорого.
Ошибка в том, что вы думаете, что платите за использование 6 127 000, но на самом деле у вас уже через 30 дней остаётся на 500 000 меньше. Взятые 6 127 000 должны при таком раскладе должны приносить бешеную прибыль, чтобы окупиться.
Формулы из статьи позволяют оценить жадность банка. Если он депозиты берет под 6%, а кредиты выдаёт под 20%, то это очень жадный банк.
В корпоративном приложении верная архитектура это когда можно быстро найти и изменить нужный код. А когда код пишут с расчётом на расширение плагинами или интерфейсами вот это как раз очень плохая архитектура.
Я на этом завалился лет 5 назад. Я когда-то давно занимался олимпиадным программированием и думал с задачами проблем не будет. Но там была откровенная жесть, кони с доской отдыхают. Я потом похожие задачи находил на олимпиаде уровня чемпионата ЮАР, а это уже какой-никакой уровень, без тренировки и подготовки такое не решить. Я гарантирую, только человек который достаточно активно решает олимпиадные задачи мог бы это решить за отведённое время.
Пришёл к выводу, что варианта два
Повезло и задачи простые
Задачи не решать, но отправить что-то, что пройдёт хотя-бы 10% тестов. 4 задачи дадут приемлемую сумму баллов.
Кажется вариант 2 это самая рабочая схема.
>Посчитайте снова. Ваш расчёт должен дать коэффициент использования 10%, а не 1%. И такая ошибка сильно повлияет на выбор технологии.
В моем расчете нет никакого коэффициента использования. Есть пиковая нагрузка, для которой нужно 300 машин, которая бывает 15 дней в году. Что изменится если она бывает 100 дней в году? Только то, что облако станет менее эффективным с точки зрения денег. А если 300 машин надо 365 дней в году и никаких всплесков нет, то облако вообще пролетает. Предсказывать всплески на этапе выбора архитектуры так себе занятие.
>Это тоже искажающее картину соображение. Если бизнесу что-то реально надо - они найдут сервера за один день (ну поусть неделю).
Бизнес это не человек, ему ничего не надо и он ничего не чувствует. Как по вашему "ему надо" должно работать? Железного сервера нужной комплектации от нужного производителя может не быть в России или в вашем городе. Можно закупать что есть и получить зоопарк железа, каждое с своими особенностями. А еще договор на поставку нужно с юристом обсудить, а затем в фин. дирктором. А он в отпуске. А затем менеджер со стороны поставщика ушел в отпуск или заболел. А затем поставщик не ту конфигурацию прислал или не те реквизиты выслал. И пошло поехало.
Пусть менеджер проекта сам закупает технику без лишнего контроля и процедур? И вот у нас откаты менеджеру от поставщиков и полный бардак с тем, кто кому сколько должен, какой товар уже пришел, какой к возврату, а какой получили, где все это находится и в каком состоянии.
И пример закупок из практики - купить и вернуть полотенцесушитель за 20 тыр. - 50 писем поставщику и обратно, пара рабочих дней времени. И это ИП покупает для себя, без процессов и контроля. Боюсь реальность закупок чего-то сложнее еды в магазине или книги на озоне вас может очень разочаровать.
>> А отдать лишнее железо производителю не получится
>И это не проблема.
Предлагаете все тренировать GPT-3 на свободных мощностях? Вот только как инициатор этого проекта вообще узнает о том, что есть свободные мощности? Сколько людей и ИТ систем должно слажено работать вместе, чтобы появилась таблица с свободными серверами, чтобы к ним был доступ у кого надо, чтобы на них можно было запускать GPT-3 и так далее. Все можно, но это не просто так дается.
>Так же и вы - выделяйте виртуалку и нарезайте ресурсы кому нужно.
Это очень упрощенное представление о правах доступа и сценариях с ними. Дело не в виртуалках совсем.
>Я вам не подскажу конкретные инструменты такого плана, но я очень сильно сомневаюсь в том, что их нет для обычных серверов, но есть исключительно для облаков.
Есть конечно. Для каждой задачи есть какой-то отдельный тул, который ее решает. Связывать и настраивать все это для совместной работы - фул тайм работа для нескольких, далеко не дешевых, человек.
Например, взяли вместо AWS Systems Manager альтернативу, которая на самом деле даже круче - RunDeck. А еще у нас есть Active Directory где юзеры живут. И в RunDeck тоже есть юзеры, с какими-то правами на запуск тех или иных скриптов. И вот кто-то сидит и пилит интеграцию Active Directory <-> RunDeck чтобы из AD можно было рулить тем, кто что может и не может делать.
Или хотим логи - подняли ELK, интегрировали его с AD. Но как теперь разделить права юзеров, кто может видеть логи проекта А, а кто нет? И опять кто-то сидит и пилит интеграцию. Можно забить и в каждый проект свой приватный ELK развернуть. Теперь у вас N источников проблем с обновлением софта и починкой сломавшихся индексов.
Бекапы БД, ну да, есть open source тулы, но их надо настроить, а они еще могут ломаться. А затем нужно права доступа для бекапов настроить. И вот опять AD и интеграция. И так далее до бесконечности.
Понятно, что по среднему никто не берет. Поэтому если для средней нагрузки нужно 30 машин, то вы возьмете 300, чтобы выдержать прыжок в 10 раз. Мы тут считаем, что архитектура хороша и 300 машин действительно нужны.
В облаке вы 350 дней в году используете 30 машин, а 15 дней в году 300. В своем дата центре вы 365 дней в году используете 300 машин на 1% в среднем. Вот в такой ситуации и возникает экономия, а serverless упрощает масштабирование, но имеет свои нюансы.
Есть другие нюансы. В большой организации вы можете ждать сервер по полгода и больше, пока отдел закупок тендер сделает, пока привезут. Если та же организация использует облако, то вы просто заказываете сервер. С другой стороны компания где я сейчас работаю платит AWS миллионы $ в год за железо, которое никому не нужно. С третьей стороны, найти и отдать это железо AWS задача на несколько дней, что регулярно происходит. А отдать лишнее железо производителю не получится. И это лишнее железо, скорее всего, будет привязано к конкретному отделу/команде, а сделать так, чтобы лишнее железо можно было найти и переместить из отдела в отдел это та еще организационная задача.
Также IAM - то есть возможно управлять доступом. В облаке это встроено и работает на любом масштабе, будь то 10 или 10 000 разработчиков. С своим железом и в большой компании вы будете иметь отдел админов, которые будут пилить правила контроля доступа. Обыденные штуки, вроде перешел человек из команды в команду и ему нужны доступы, могут стать целой задачей, с тикетами, менеджерами, админами-исполнителями.
Свое железо - хорошо, облако - тоже хорошо. Просто есть нюансы где одно и другое работает лучше или хуже. Я сначала мигрировал свой небольшой бизнес из AWS на bare metal в OVH и сэкономил несколько тысяч USD в месяц. А сейчас думаю над обратной миграцией, потому что подрос и хочется IAM, ECS, Secrets Manager, Systems Manager и RDS. Делать все это руками на своем железе очень долго и дорого.
Как любой уважающий себя миллионер я знаю, что хранить деньги в долларах это глупо. И знаю я это уже очень давно, потому что ставки по депозитам уже лет 10 или даже больше находятся районе 0%. Поэтому я храню деньги в облигациях, акциях и недвижимости. Эти инструменты с сохранением и преумножением богатства справляются довольно неплохо, особенно золото, недвижимости и бонды.
Наличные не были инструментом сохранения денег. Во всяком случае с конца 20 века и до наших дней.
Отрицательные ставки и вертолетные деньги были до ковида. Кейнсианство вам в помощь, там деньги этот даже не товар, э нечто вроде сигнальной системы, как нейромедиатор в организме. И потому печатать их можно и нужно для поддержания нормального уровня функционирования экономики.
>сейчас эти напечатанные деньги особо у людей не задерживаются, так как они потеряли свой основной источник дохода и вынуждены их сразу потратить.
Разве это плохо? Копить деньги хорошо?
> А там, по отработанным каналам, денежки возвращаются обратно к хозяевам ))
Разве это плохо? Хозяевам же плевать на бумагу, они ее сами печатают и от того, что к ним она вернулась не холодно и не жарко. Разве не так?
>Поскольку крупнейшие владельцы валюты в мировых финансовых центрах заинтересованы именно в росте своего капитала, т.е в повышении цены денег, а значит - в увеличении спроса на них и росте кредитной ставки. Поэтому они создают дефицит, максимально снижают предложение денег на валютных рынках.
Поэтому они печатают деньги и ставки у них отрицательные?
Касательно первого анекдота - люди голодные потому что ресурсы неправильно распределяются, а не потому, что денег напечатать забыли. А модели вроде капитализма или социализма это алгоритмы призванные обеспечить распределение ресурсов. Работают так себе, но это лучшее, что у нас есть.
Со многим согласен. Но не понятно как на своём выделенном железе отмасштабироваться в 10 раз, пусть даже на это уйдёт 10 и более минут.
Если append fsync always то разница будет только на чтении, запись может быть даже медленне чем в БД. У Redis есть ещё кластер, можно смириться с возможной потерей данных, можно организоваться свой WAL на уровне app server. Вариантов много, зависит от профиля нагрузки. Основная идея в том, чтобы использовать очень быстрый, специализированный storage, который позволит пики проходить, не упираясь в БД.
У вас пиковая нагрузка такова, что вам нужно 300 машин. Но 99% времени вам хватит 30. Так и получается экономия на serverless - за счёт автомасштабирования. Можно его сделать на основе API облака и пачки костылей, но работать будет хуже и поддержка будет дорогой.
Это единственный кейс где serverless рулит, если система под него заточена. Но на практике скачки нагрузки в десятки раз именно на базу редко где встретишь. А там где они есть можно пошаманить и данные хранить в Redis, а писать в БД пачками.
Прочитал пост на Reddit, выглядит как fake news. По пунктам
Mixed results выглядит как попытка использовать коннект к БД в разных потоках. Характерно, что вылезает на нагрузке.
Timeout error это проблема любой БД, а не только serverless. Если случилась ошибка сети, то вы знаете, что стало с транзакцией.
Too many connections и прочие ошибки вам нужно обрабатывать в любом случае, если у вас high-load.
Предьявить AWS можно за документацию. Остальное выглядит как столкновение с реальностью распределённых и нагруженных систем.
Речь же о том, что вы такие идеи генерите регулярно. Нужно всего-то придумать что-то, что можно сделать самому без инвест фонда и озолотиться. Если же все идеи требуют обязательно миллионов usd инвестиций и вы не знаете откуда их взять, то 99.9% это не идеи, а сказки и мечты.
Ваш пример это пример хорошего рац. предложения. Если вы активно в создании и внедрении участвовали, то точно достойны хорошей премии. Но даже если премии нет, то на эксплуатацию эта ситуация не тянет. Просто рабочий эпизод.
Какому бизнесу хорошо от того, что в один день счёт за облако 3 цента, а в другой $30 000 мне не понятно. Хотя AWS такая ситуация точно нравится.
Пропорциональное участие в прибыли предполагает пропорциональное участие в убытках. Поэтому покупайте акции и наслаждайтесь результатом своего труда. Боюсь лучше варианта не существует.
>Но этот вариант не сказать чтоб прям идеален был, так как слишком слабая связь между твоей старательностью и выхлопом от всей корпорации.
В том-то и проблема, индивидуальный вклад в выхлоп посчитать нереально. Поэтому и существую привычные формы отношений - продажа продуктивного времени (зп) или продажа конкретного результата (фикс, сдельная оплата).
>Потому по-настоящему горячий энтузиазм может быть только в стартапах среди тех работников, кому принадлежит солидный процент от компании.
Это миф из фильмов и корпоративной мифологии. Никто не будет рвать попу ради призрачного шанса через 5 лет разбогатеть. Будут работать как обычно, но говорить о 80 часовой рабочей неделе. Основатель будет это миф будет культивировать, он помогает увеличить стоимость компании. Можете посмотреть на обсуждения работы в стартапах на hacker news, там видно реальное отношение.
>Одно дело если я сумел очень быстро найти и поправить сложный баг и дальше отдыхаю часок
Думаю с этим никто не будет спорить. Речь о ситуациях когда поправил баг и отдыхаю остаток рабочей недели. Реальная история - разработчик едет на машине из Питера в Крым, ноутбук открыт и он типа работает, трекает время. Жена на заднем сидении тыкает в кнопки, чтобы трекер не ругался. Ну а что? Он же отлично поработал на прошлой неделе, он же 10х программист, а злой капиталист его эксплуатирует, так что пусть платит.
История про «надо доверять команде» не работает так, как обычно говорят. Доверять гражданам надо, но и полицию иметь следует. То есть нужны методы контроля и они будут нормальным людям мешать. И будут создавать серые зоны, типа попить чаю час или два после фикса бага. И эти зоны будут источником конфликта, так как у всех своё понятие о рамках приличия. Но это не значит, что работодатели говнюки или сотрудники мудаки.
Эта ситуация и есть обман. Вы продаёте продуктивное время, не идеи, не результат работы, а именно время. Хотите продавать результат, заключаете фикс. контракт и доставляете результат, нет проблем. Но отношения сотрудник-работодатель подразумевают исполнение обязанностей в течение времени.
Непонятно как считать прибыль от идеи, если придумал Вася, сделал Петя, продаёт Маша, а рынок растёт/падает сам собой? А если идея провалилась, то надо депримировать? И в конце концов - если вы такие золотые идеи генерируете, то почему сами не реализуете и не получите свои 100 окладов с рынка? Пока получается не очень красивая концепция - меня несправедливо эксплуатируют, поэтому я не буду соблюдать договоренности (исполнение обязанностей в течение времени). Можно было бы в это поверит, но у нас рынок кандидатов, о какой эксплуатации тут вообще может идти речь?
Вы попробуйте руководить командой удаленщиков человек в 10-20. Я это делаю последние 10 лет. Мой опыт - при активном найме за 6 месяцев гарантировано будет хотя бы один персонаж, который левачит. Ещё найдутся люди, которые просто пинают балду. Очень часто люди на удаленке понимают, что работать 8 часов в день как-то лениво. Я бы с удовольствием покупал результат и платил фикс по факту выполненных работ. Но так не хотят, обычно хотят зп, а это продажа продуктивного времени. Если покупал 8 часов, а продают 4 - это обман, как не крути. Устал писать код, можно делать ревью, улучшать документацию, участвовать в митинге, обучаться и так далее. Далеко не все задачи программиста на самом деле требуют мега сосредоточенности.
Трекеры это необходимое зло. Только очень стабильная команда может без них обойтись. А если есть хотя бы средняя текучка (работают 2-4 года) и размер команды (5-15 человек) и не дай боже рост, то вы быстро наберёте очень интересных, дорогих и неэффективных персонажей.
В мире удаленки гораздо проще и честнее оплачивать фактически отработанные часы. Не нравится продуктивность/час - расстаётесь. А если результата нет, но и часов нет, то все ясно и нет проблем.
>Вообще для меня программирование — это уже давно постоянная коммуникация.
Половину qsort изобрёл один напарник, а вторую другой, про это речь? В 15м веке было парное рисование картин. Только работало оно гораздо разумнее. Подмастерья рисовали неважные куски по эскизам мастера. И несложно увидеть, что это ускоряет дело. А как дело ускорит обмен данными со скоростью пару килобайт в минуту и кучей ошибок в канале непонятно совершенно.
Гипотеза - слишком много времени затрачено на программирование и слишком мало на социализацию. В итоге проще не тусоваться в ИРЛ.
>И вам изначально назначают зарплату, исходя из оценки вашей продуктивности. И делают переоценку каждый год, на основе этой продуктивности.
Зп зависит не от продуктивности, а от баланса спроса и предложения. Самый сильный предиктор ожидаемой зп - возраст, а не способности, реальные или предполагаемые, кандидата. Мне жат ситуация не нравится, но так уж рынок устроен.
Если разработчик работает на 2х работах, то его продуктивность на каждой это далеко не 50%, скорее 20%. Переключение контекста между задачами стоят очень дорого.
Ошибка в том, что вы думаете, что платите за использование 6 127 000, но на самом деле у вас уже через 30 дней остаётся на 500 000 меньше. Взятые 6 127 000 должны при таком раскладе должны приносить бешеную прибыль, чтобы окупиться.
Формулы из статьи позволяют оценить жадность банка. Если он депозиты берет под 6%, а кредиты выдаёт под 20%, то это очень жадный банк.
В корпоративном приложении верная архитектура это когда можно быстро найти и изменить нужный код. А когда код пишут с расчётом на расширение плагинами или интерфейсами вот это как раз очень плохая архитектура.