Названия исторически сложились ещё до моего присоединения к компании. На самом деле, просто взяли первое готовое юридическое лицо, это был "АйТи Мегастар". По-моему, оно было под рекламную компанию.
По поводу решений и объёмов. Скорее сложность бывает "Мега", иногда кажется, что компания ежегодно проходит "смертельный марш". Предпоследний такой заход, был связан с внедрением портала электронного документооборота (написана с нуля) в очень крупном российском ритейлере. При условии, что под это дело перестраивались бизнес-процессы в компаниях заказчика (а их там было более, чем несколько) и это уже была где-то пятая попытка. остальные провалились до нас.
И нельзя, чтобы бизнес тянули такие "золотые шестеренки". Дело не в том, что они не могут. Дело в том, что в какой-то момент они будут тянуть не ваш, а свой бизнес.
Если учесть все накладные и сопутствующие расходы, то выйдет, что "талант" будет стоит заметно дороже. Конечно, если только вы не компания с очень маленькой командой, тогда дисбалансы по вам будут бить не сильно. Ну, либо вы каким-то образом можете набирать много "талантов", но тогда эти "таланты" уже не таланты для вас.
Ну, если только это не Senior solution architect, иногда это бывает Head of чего-то там. Обычно senior developer особой разрушительной силы с собой не несут. Хотя есть проблема, что один сеньор может работать раз в десять лучше другого сеньора, при этом они оба сеньоры заслуженно. Это может мешать баланса в командах достичь.
Это действительно так, но реализовать это придётся уже не на уровне PostgreSQL. Хотя есть такая вещь, как транзакция, и можно смотреть общее время её выполнения. Долгими они тоже не должны быть, чтобы не начать ловить дедлоки из-за блокировок на чтение и запись.
Кроме того, информацией о транзакцией обладает сервер с бизнес-логикой (написан на Python и C++). Этот сервер предоставляет API, время которого тоже можно отслеживать. Такие рейтинги тоже были, но контролировались не так плотно.
Ну и частота вызова метода API и SQL-запроса тоже имеет значение. Чем чаще вызывается, тем больше может быть потребность в оптимизации. Суммарное время и потребление памяти тоже отслеживалось.
Понять, что с запросом происходит что-то не то на продуктивных данных, можно только в момент его выполнения. Поэтому мы сейчас говорим о системе логирования времени выполнения запросов и планов их выполнения. И системе мониторинга самых долгих и тяжёлых запросов. Планы же запросов нужны, чтобы понимать, что пошло не так. Не попали в индекс, спровоцировали sec scan либо ещё что-то подобное.
Тут все не так просто. Кроме времени выполнения запроса там логировался даже план выполнения запроса. В зависимости от плана выполнения запроса очень сильно меняется время его выполнения. Обычно есть несколько разных способов записать в целом один и тот же запрос, на больших и сложных данных время выполнения разных форм одного и того же запроса могут отличаться в сотни раз. Потому, что планировщик и оптимизатор PostgreSQL штука умная, сложная, учитывающая статистические данные, но не всесильная. Иногда план запроса не попадает в нужные индексы, иногда нужного индекса просто нет. Иногда все ломается (оптимальный план запроса) от простого джойна.
То есть здесь именно тот случай, когда машинная оптимизация не справилась и нужно человеческое участие. На самом деле, PostgreSQL здесь не уникален. Похожим образом может происходить оптимизация запросов для MS SQL, Oracle и других реляционных баз данных.
В целом не так страшно. Задачи декомпозируются по пользовательским сценариям, поэтому получается не так уж много демонстраций. Плюс, мы предпочитаем поэтапную сдачу проектов. Каждый этап демонстрируется заказчику менеджером.
За счёт таких демонстраций и подготовки к ним, повышается качество и ускоряется разработка. Люди привыкают заканчивать свои задачи целиком, и не попадать в ситуации, когда проект закончен на 95%, а времени нужно на него потратить ещё столько же, сколько потратили.
Страничка не открывается — это тривиальная ошибка, которая должна быть замечена ещё на этапе отладки. В крайнем случае, на смок-тесте. Отсутствие 404 и 500 страницы — это тривиальные ошибки. Невыполнение основных сценариев — тривиальная ошибка.
Нетривиальная ошибка, это когда вы открываете ленту событий, подгружаете ещё два блока данных, вставляете комментарий со спецсимволом, и при загрузке четвёртого блока данных у вас вёрстка разъезжается. То есть сценарий воспроизведения сложный и неочевидный.
Здесь основной момент в том, что человек готовит демонстрацию, прогоняет сценарии для неё перед тем, как показать другим. Это организационный приём, чтобы убедиться, что человек при отладке выполнил основные сценарии, а не просто послал задачу на тестирование без смок-теста.
Можно показывать не QA, а менеджеру. Воспитательный эффект будет тот же.
Есть банальный тест на понимание происходящего (касается не только C++), это использование конструкции типа array.append(). То есть добавление нового элемента в конец массива с перевыделением памяти. Это дорогая операция за счёт необходимости выделить память под новый массив, перенести данные из старого места в новое, очистить память из под старого массива. Если такую конструкцию запустить в цикле на тысячи записей, то вместо продуктивной деятельности компьютер займётся постоянным перевыделением памяти.
Если мы говорим конкретно о STL, то классы там спроектированы весьма разумно. Но, например, есть операции типа vector::insert, которые требуют понимания того, что ты хочешь сделать. Конечно, кроме std::vector есть более подходящий для вычислительной математики std::valarray. Но есть нюанс в том, что стандарт не определяет реализацию.
В случае, когда у нас более-менее сложный код, то в каких-то функциях, которые вызываются циклически, может присутствовать объявление vector с большим объёмом. Тут тоже будет очень много затрат на выделение и освобождение памяти.
Отсюда первая проблема. В целом была сделана большая работа над тем, чтобы людям можно было меньше думать о выделении памяти, и чтобы снизить опасность утечки памяти. Вот теперь люди и перестали о этом всем думать, появились ощутимые проблемы с производительностью.
Идём немного дальше. Например, у меня есть объёмная матрица в плотном формате, то есть некий двумерный массив, а обходить мне нужно её определенным способом. В кеш процессора она вся не влезет, так как может занимать гигабайты, значит процессор будет вынужден решать какой её кусочек нужно скопировать в кеш. То есть если это N массивов по N элементов, это одна ситуация, если это один массив из N*N элементов, то совершенно другая. Чтение из физической памяти меняется. Здесь уже могут начинаться проблемы с тем, что реализацию STL никто не регламентирует.
Возможно, мне самому будет удобно знать формат физического хранения данных. Например, я пользуюсь MPI и мне нужно передать кусок данных на другой узел. Одно дело, если я могу просто выхватить область физической памяти и послать её, другое дело, когда я должен заниматься упаковкой и распаковкой.
Есть ещё извращения, когда происходит умышленный выход за пределы массива (нужно же знать куда выходишь), либо использования одного и того же фрагмента памяти для хранения данных сильно разных структур. Но это очень спорные моменты.
Конечно, я и на STL могу сделать то, что обычно делаю без него. Тут больше роль играет то, что он помогает людям забыть, что они работают с памятью. Иногда это вредно и лучше некоторые вещи в коде показывать в явном виде. Иногда, код не так интенсивно работает с памятью и можно писать с соблюдением «общепринятых подходов».
От стрельбы себе в ноги спасает опыт и отладка, при которой тесты подбираются таким образом, чтобы сразу видеть проблемы с некорректным использованием памяти.
Наоборот. Когда умеешь работать с памятью, в том числе с общим полем и разделенным полем памяти, такие вещи начинают мешать. Если мы говорим, про научный код, конечно.
А в обычной коммерческой разработке, конечно, это все придется использовать. То, что я не выстрелю себе в ногу ещё не значит, что кто-нибудь другой по своей неопытности не начнет палить по ногам (себе и другим).
Генеральный директор же не в вакууме работает. Вокруг него есть команда. Команда вряд ли захочет уступать место. Придется делать выбор. Вот это первое, на что вы натолкнетесь.
Конечно. Вот поставьте себя на место генерального директора, на которого абсолютное большинство в компании смотрит потребительски, прямо как на еду. Он для них и средство извлечения дохода (без него компания не будет такой успешной), и способ снять с себя какую-либо ответственность. А то что он иногда ругается и грозит уволить, так это мелочи, можно и потерпеть. Благо, что почти не увольняет.
И тут в такой среде внезапно появляется золотая шестерёнка, которая смотрит на вас, как на человека, понимает ваш бизнес и помочь вам пытается. Со временем этот человек растёт и ему становится тесно в вашей организации. Конечно, вы отпустите такого человека на волю, а не сделаете его пищей для среды, которая и вас-то пытается съесть.
А если этот человек ещё и вырастет во что-то сопоставимое с вами, так с ним вообще можно просто дружить начать.
Вы хорошо написали, с вами даже хочется согласиться. Вот только эта сказочная система никогда не заработает. По той же причине, почему коммунизм и социализм не состоялись, - природа человека. Не руководителей, исполнителей, как не странно.
Например, я знаю, что если у моего бывшего работодателя уменьшить штат ИТ-шников раза в 4 и снизить им зарплаты раза в два, то производительность компании даже не снизится. Дело не в том, что людей не хватает.
Дело в том, что эти все люди большую часть сил тратят на противодействия друг другу. А делают они это прежде всего из-за того, что у них с компанией нет общей цели, но есть желание взять побольше, а отдать поменьше. То есть как раз нарушить баланс интересов и ценности в свою пользу. Как результат, они сами же превращают свою же жизнь в ад. Страдают и терпят за деньги, более жёстко выражаться не буду.
С точки зрения бизнеса ситуация ещё проще. Бизнес работает с тем, что есть. У него нет задачи сделать хорошо и правильно, у него есть задача сделать лучше, чем конкуренты. А у конкурентов ещё больший адища, не смотря, что они пытаются поступать так, как вы написали. Чем больше ресурсов вольёшь в систему, тем хуже в ней станет людям. Чувство меры же есть не у всех людей.
Конечно, можно говорить о командах мотивированных профессионалов-созидателей, но в реальной жизни такие команды существуют очень редко. И это не очень устойчивые конструкции из-за своего размера. Так как люди не мешают друг другу и не обманывают друг друга, то их и нужно очень немного. Из-за малочисленности потеря члена группы очень болезненна. А люди могут менять работу по куче разных причин, от переезда в другую страну, до просто ситуации, когда человеку надоело работать и он поехал медитировать в Гималаи лет на 10.
Золотую шестерёнку опасной делает умение управлять локальным пространством вокруг себя, заряжать людей общей целью и вести за собой, при этом ещё на ходу прикидывая оптимальный путь. В результате какой-то кусочек компании внезапно для всех начинает работать с чудовищной эффективностью, ломая сопротивление людей вокруг. Именно ломая, насильно, через кровь и боль, лишая их возможности поработать поменьше да взять побольше.
Потом золотой шестерёнке становится тесно в рамках компании, ей хочется большей самореализации, для которой есть и потенциал, и способности. Приходится решать, что с этим делать. Зачастую, такого человека просто отпускают на волю. Как не странно, это ещё позволяет сохранить хорошие отношения при расставании.
Понятно, что проблемы есть всегда и технический долг в иные моменты оправдан и неизбежен. Суть проблемы в другом.
То, что названо «золотой шестерёнкой» не может постоянно существовать в установившейся системе обычного вида. Она будет постепенно всплывать на уровень высшего руководства, после достижения которого начнутся уже политические проблемы.
Во-первых, этой золотой шестерёнке уже кому-то придётся уступить место. А этот кто-то может начать сопротивляться всей своей политической и административной властью. Во-вторых, золотая шестерёнка потянет наверх и свою команду. То есть будет осуществляться транзит власти от одной управляющей команды к другой. Это тоже может вызывать сильное сопротивление.
Попытка выделить новую команду в новое же начинание может вызывать политические проблемы уже во всей структуре организации. Банальный вопрос, почему им можно, а мне нельзя. Кроме того, будет обоснованный страх. Ведь если новые подходы сработают, то тех, кто уже приспособился к старой системе заставят работать. Это будет выброс из зоны комфорта.
Для стабильной и установившейся системы это может выглядеть, как неприемлемая цена. Для зонтичной структуры в момент её разворота, при должной смелости руководства (которое на самом деле просто собирается сделать левел-ап и пойти дальше), это может стать приемлемым вариантом.
Нет организация, которые подходят всем подряд. И нет людей, которые подходят к любому типу организации. Беря в руки золотую шестерёнку, нужно понимать, что это мощный и опасный инструмент, таким нужно пользоваться осознанно.
Почему вы позволили себе проигнорировать заданные вам вопросы? Если вам нечем на них ответить, можно просто извиниться за свою ошибку.
Конечно, контекст задан статьёй. Просто вы этот контекст игнорируете и начинаете придумывать что-то своё вместо этого контекста.
Касательно таблицы. Вот вы сами пишите, что у вас для таблицы на 100 000 записей и 5 столбцов опера потребляет 1.6 гб. Можно предположить, что если мы возьмём не 5 столбцов, а 16, то есть в 16/5 = 3.2 увеличим объем данных, то у нас и потребление памяти вырастит пропорционально (для простоты) вырастет. Имеем верхнюю оценку в 1.6*3.2 = 5,12 гб. Понятное дело, что скорее всего будет несколько меньше, вот только пользователю у которого всего 5 гб оперативной памяти, большая часть которой уйдёт на обслуживание ОС, легче от этого не станет.
С учётом того, что Опера использует WebKit, как и Chromium и Google Chrome, вызывает интерес, как вы делали замеры. У вас потребление памяти у Оперы и Хрома почти на порядок отличаются. Ведь по вашим словам Опера потребляет 1.6 гб, а Хром всего 180 мб.
Но это все не суть, потому, что вы проигнорировали тот факт, что ячейка таблицы — это компонент, который в свою очередь состоит из html-элементов, которые и идут в DOM-дерево. То есть ваши замеры нужно умножать ещё в 10-15 раз. И это только таблица без всего прочего окружения.
Здесь только добавить, что автор не ругал CEO и программистов, которых нанимал сам. Программистов в других филиалах нанимал не я, отвечать за них не мне. Ну и их, я тоже не ругал. Команды разработки платформы (центральный офис, кстати) — да, а вот обычных разработчиков — нет.
Чего ещё добавить. Посыл про «разгребание» тоже не верный. Доработка моего функционала силами моей же команды никаких проблем не вызывала. Это происходило быстро и с заметно более низким количеством ошибок, чем у ребят из соседних филиалов. Проблемы были не у нас, а у тех, кто попробовал это подхватить. Именно они не справились с интенсивностью и нагрузками. Наверное, это они не состоялись, как управленцы?
Кроме того, я же не зря написал, что кроме непосредственно написания кода, и непосредственно руководства одной из команд разработки, я ещё целым филиалом разработки управлял, где моя команда существовала далеко не в единственном числе. Нас много там таких было. Думаю, меня, как управленца характеризует вот этот фрагмент: «...На самом деле, компания теряла только сильного разработчика и, возможно, его команду. В филиале оставалась очень сильная и слаженная команда руководителей. Потом, после того, как решатся проблемы с площадями, эта команда руководителей в неизменном составе отмасштабирует филиал разработки раз в 5. Этим достижением я горжусь…».
Ушёл я потому, что нащупал свой потолок профессионального роста в компании. Дальше только входить в «семью», а для этого желательно обитать в центральном офисе. Плюс политические расклады не позволили маневрировать даже CEO, который ещё и основным владельцем компании был.
Поэтому, я пошёл расти дальше и в другие места. Для бывшего работодателя тоже катастрофы не произошло. На их объемах это был всего лишь маленький укольчик и мелкая неприятность. Там такого и без меня могло периодически происходить.
При моём уходе основная тема переговоров была, чтобы я не трогал команду руководителей, которые все со мной очень хорошо дружили. Деловая этика быстро позволила нам договориться.
Вот только не всегда и не все золотые шестерёнки настолько лояльны к бывшим работодателям. Об этом нельзя забывать.
В целом согласен с вами, но тут ещё более тяжёлая ситуация. Я больше года пытался передать эту экспертизу и знания тем лицам, у кого она должна была быть. Они мастерски уворачивались от вручения этих знаний и экспертизы. Оказывается вручить экспертизу — особый вид искусства.
В какой-то момент мне надоело рассказывать, какие будут последствия, потом пришлось их показать в живую.
Названия исторически сложились ещё до моего присоединения к компании. На самом деле, просто взяли первое готовое юридическое лицо, это был "АйТи Мегастар". По-моему, оно было под рекламную компанию.
По поводу решений и объёмов. Скорее сложность бывает "Мега", иногда кажется, что компания ежегодно проходит "смертельный марш". Предпоследний такой заход, был связан с внедрением портала электронного документооборота (написана с нуля) в очень крупном российском ритейлере. При условии, что под это дело перестраивались бизнес-процессы в компаниях заказчика (а их там было более, чем несколько) и это уже была где-то пятая попытка. остальные провалились до нас.
И нельзя, чтобы бизнес тянули такие "золотые шестеренки". Дело не в том, что они не могут. Дело в том, что в какой-то момент они будут тянуть не ваш, а свой бизнес.
Если учесть все накладные и сопутствующие расходы, то выйдет, что "талант" будет стоит заметно дороже. Конечно, если только вы не компания с очень маленькой командой, тогда дисбалансы по вам будут бить не сильно. Ну, либо вы каким-то образом можете набирать много "талантов", но тогда эти "таланты" уже не таланты для вас.
Ну, если только это не Senior solution architect, иногда это бывает Head of чего-то там. Обычно senior developer особой разрушительной силы с собой не несут. Хотя есть проблема, что один сеньор может работать раз в десять лучше другого сеньора, при этом они оба сеньоры заслуженно. Это может мешать баланса в командах достичь.
Это действительно так, но реализовать это придётся уже не на уровне PostgreSQL. Хотя есть такая вещь, как транзакция, и можно смотреть общее время её выполнения. Долгими они тоже не должны быть, чтобы не начать ловить дедлоки из-за блокировок на чтение и запись.
Кроме того, информацией о транзакцией обладает сервер с бизнес-логикой (написан на Python и C++). Этот сервер предоставляет API, время которого тоже можно отслеживать. Такие рейтинги тоже были, но контролировались не так плотно.
Ну и частота вызова метода API и SQL-запроса тоже имеет значение. Чем чаще вызывается, тем больше может быть потребность в оптимизации. Суммарное время и потребление памяти тоже отслеживалось.
Понять, что с запросом происходит что-то не то на продуктивных данных, можно только в момент его выполнения. Поэтому мы сейчас говорим о системе логирования времени выполнения запросов и планов их выполнения. И системе мониторинга самых долгих и тяжёлых запросов. Планы же запросов нужны, чтобы понимать, что пошло не так. Не попали в индекс, спровоцировали sec scan либо ещё что-то подобное.
Тут все не так просто. Кроме времени выполнения запроса там логировался даже план выполнения запроса. В зависимости от плана выполнения запроса очень сильно меняется время его выполнения. Обычно есть несколько разных способов записать в целом один и тот же запрос, на больших и сложных данных время выполнения разных форм одного и того же запроса могут отличаться в сотни раз. Потому, что планировщик и оптимизатор PostgreSQL штука умная, сложная, учитывающая статистические данные, но не всесильная. Иногда план запроса не попадает в нужные индексы, иногда нужного индекса просто нет. Иногда все ломается (оптимальный план запроса) от простого джойна.
То есть здесь именно тот случай, когда машинная оптимизация не справилась и нужно человеческое участие. На самом деле, PostgreSQL здесь не уникален. Похожим образом может происходить оптимизация запросов для MS SQL, Oracle и других реляционных баз данных.
Очень интересный случай, спасибо.
В целом не так страшно. Задачи декомпозируются по пользовательским сценариям, поэтому получается не так уж много демонстраций. Плюс, мы предпочитаем поэтапную сдачу проектов. Каждый этап демонстрируется заказчику менеджером.
За счёт таких демонстраций и подготовки к ним, повышается качество и ускоряется разработка. Люди привыкают заканчивать свои задачи целиком, и не попадать в ситуации, когда проект закончен на 95%, а времени нужно на него потратить ещё столько же, сколько потратили.
Страничка не открывается — это тривиальная ошибка, которая должна быть замечена ещё на этапе отладки. В крайнем случае, на смок-тесте. Отсутствие 404 и 500 страницы — это тривиальные ошибки. Невыполнение основных сценариев — тривиальная ошибка.
Нетривиальная ошибка, это когда вы открываете ленту событий, подгружаете ещё два блока данных, вставляете комментарий со спецсимволом, и при загрузке четвёртого блока данных у вас вёрстка разъезжается. То есть сценарий воспроизведения сложный и неочевидный.
Здесь основной момент в том, что человек готовит демонстрацию, прогоняет сценарии для неё перед тем, как показать другим. Это организационный приём, чтобы убедиться, что человек при отладке выполнил основные сценарии, а не просто послал задачу на тестирование без смок-теста.
Можно показывать не QA, а менеджеру. Воспитательный эффект будет тот же.
Как врезка (а не цитата), текст бьётся на блоки и лучше читается. Плюс акценты расставляются.
Есть банальный тест на понимание происходящего (касается не только C++), это использование конструкции типа array.append(). То есть добавление нового элемента в конец массива с перевыделением памяти. Это дорогая операция за счёт необходимости выделить память под новый массив, перенести данные из старого места в новое, очистить память из под старого массива. Если такую конструкцию запустить в цикле на тысячи записей, то вместо продуктивной деятельности компьютер займётся постоянным перевыделением памяти.
Если мы говорим конкретно о STL, то классы там спроектированы весьма разумно. Но, например, есть операции типа vector::insert, которые требуют понимания того, что ты хочешь сделать. Конечно, кроме std::vector есть более подходящий для вычислительной математики std::valarray. Но есть нюанс в том, что стандарт не определяет реализацию.
В случае, когда у нас более-менее сложный код, то в каких-то функциях, которые вызываются циклически, может присутствовать объявление vector с большим объёмом. Тут тоже будет очень много затрат на выделение и освобождение памяти.
Отсюда первая проблема. В целом была сделана большая работа над тем, чтобы людям можно было меньше думать о выделении памяти, и чтобы снизить опасность утечки памяти. Вот теперь люди и перестали о этом всем думать, появились ощутимые проблемы с производительностью.
Идём немного дальше. Например, у меня есть объёмная матрица в плотном формате, то есть некий двумерный массив, а обходить мне нужно её определенным способом. В кеш процессора она вся не влезет, так как может занимать гигабайты, значит процессор будет вынужден решать какой её кусочек нужно скопировать в кеш. То есть если это N массивов по N элементов, это одна ситуация, если это один массив из N*N элементов, то совершенно другая. Чтение из физической памяти меняется. Здесь уже могут начинаться проблемы с тем, что реализацию STL никто не регламентирует.
Возможно, мне самому будет удобно знать формат физического хранения данных. Например, я пользуюсь MPI и мне нужно передать кусок данных на другой узел. Одно дело, если я могу просто выхватить область физической памяти и послать её, другое дело, когда я должен заниматься упаковкой и распаковкой.
Есть ещё извращения, когда происходит умышленный выход за пределы массива (нужно же знать куда выходишь), либо использования одного и того же фрагмента памяти для хранения данных сильно разных структур. Но это очень спорные моменты.
Конечно, я и на STL могу сделать то, что обычно делаю без него. Тут больше роль играет то, что он помогает людям забыть, что они работают с памятью. Иногда это вредно и лучше некоторые вещи в коде показывать в явном виде. Иногда, код не так интенсивно работает с памятью и можно писать с соблюдением «общепринятых подходов».
От стрельбы себе в ноги спасает опыт и отладка, при которой тесты подбираются таким образом, чтобы сразу видеть проблемы с некорректным использованием памяти.
Наоборот. Когда умеешь работать с памятью, в том числе с общим полем и разделенным полем памяти, такие вещи начинают мешать. Если мы говорим, про научный код, конечно.
А в обычной коммерческой разработке, конечно, это все придется использовать. То, что я не выстрелю себе в ногу ещё не значит, что кто-нибудь другой по своей неопытности не начнет палить по ногам (себе и другим).
Генеральный директор же не в вакууме работает. Вокруг него есть команда. Команда вряд ли захочет уступать место. Придется делать выбор. Вот это первое, на что вы натолкнетесь.
Конечно. Вот поставьте себя на место генерального директора, на которого абсолютное большинство в компании смотрит потребительски, прямо как на еду. Он для них и средство извлечения дохода (без него компания не будет такой успешной), и способ снять с себя какую-либо ответственность. А то что он иногда ругается и грозит уволить, так это мелочи, можно и потерпеть. Благо, что почти не увольняет.
И тут в такой среде внезапно появляется золотая шестерёнка, которая смотрит на вас, как на человека, понимает ваш бизнес и помочь вам пытается. Со временем этот человек растёт и ему становится тесно в вашей организации. Конечно, вы отпустите такого человека на волю, а не сделаете его пищей для среды, которая и вас-то пытается съесть.
А если этот человек ещё и вырастет во что-то сопоставимое с вами, так с ним вообще можно просто дружить начать.
Вы хорошо написали, с вами даже хочется согласиться. Вот только эта сказочная система никогда не заработает. По той же причине, почему коммунизм и социализм не состоялись, - природа человека. Не руководителей, исполнителей, как не странно.
Например, я знаю, что если у моего бывшего работодателя уменьшить штат ИТ-шников раза в 4 и снизить им зарплаты раза в два, то производительность компании даже не снизится. Дело не в том, что людей не хватает.
Дело в том, что эти все люди большую часть сил тратят на противодействия друг другу. А делают они это прежде всего из-за того, что у них с компанией нет общей цели, но есть желание взять побольше, а отдать поменьше. То есть как раз нарушить баланс интересов и ценности в свою пользу. Как результат, они сами же превращают свою же жизнь в ад. Страдают и терпят за деньги, более жёстко выражаться не буду.
С точки зрения бизнеса ситуация ещё проще. Бизнес работает с тем, что есть. У него нет задачи сделать хорошо и правильно, у него есть задача сделать лучше, чем конкуренты. А у конкурентов ещё больший адища, не смотря, что они пытаются поступать так, как вы написали. Чем больше ресурсов вольёшь в систему, тем хуже в ней станет людям. Чувство меры же есть не у всех людей.
Конечно, можно говорить о командах мотивированных профессионалов-созидателей, но в реальной жизни такие команды существуют очень редко. И это не очень устойчивые конструкции из-за своего размера. Так как люди не мешают друг другу и не обманывают друг друга, то их и нужно очень немного. Из-за малочисленности потеря члена группы очень болезненна. А люди могут менять работу по куче разных причин, от переезда в другую страну, до просто ситуации, когда человеку надоело работать и он поехал медитировать в Гималаи лет на 10.
Золотую шестерёнку опасной делает умение управлять локальным пространством вокруг себя, заряжать людей общей целью и вести за собой, при этом ещё на ходу прикидывая оптимальный путь. В результате какой-то кусочек компании внезапно для всех начинает работать с чудовищной эффективностью, ломая сопротивление людей вокруг. Именно ломая, насильно, через кровь и боль, лишая их возможности поработать поменьше да взять побольше.
Потом золотой шестерёнке становится тесно в рамках компании, ей хочется большей самореализации, для которой есть и потенциал, и способности. Приходится решать, что с этим делать. Зачастую, такого человека просто отпускают на волю. Как не странно, это ещё позволяет сохранить хорошие отношения при расставании.
Понятно, что проблемы есть всегда и технический долг в иные моменты оправдан и неизбежен. Суть проблемы в другом.
То, что названо «золотой шестерёнкой» не может постоянно существовать в установившейся системе обычного вида. Она будет постепенно всплывать на уровень высшего руководства, после достижения которого начнутся уже политические проблемы.
Во-первых, этой золотой шестерёнке уже кому-то придётся уступить место. А этот кто-то может начать сопротивляться всей своей политической и административной властью. Во-вторых, золотая шестерёнка потянет наверх и свою команду. То есть будет осуществляться транзит власти от одной управляющей команды к другой. Это тоже может вызывать сильное сопротивление.
Попытка выделить новую команду в новое же начинание может вызывать политические проблемы уже во всей структуре организации. Банальный вопрос, почему им можно, а мне нельзя. Кроме того, будет обоснованный страх. Ведь если новые подходы сработают, то тех, кто уже приспособился к старой системе заставят работать. Это будет выброс из зоны комфорта.
Для стабильной и установившейся системы это может выглядеть, как неприемлемая цена. Для зонтичной структуры в момент её разворота, при должной смелости руководства (которое на самом деле просто собирается сделать левел-ап и пойти дальше), это может стать приемлемым вариантом.
Нет организация, которые подходят всем подряд. И нет людей, которые подходят к любому типу организации. Беря в руки золотую шестерёнку, нужно понимать, что это мощный и опасный инструмент, таким нужно пользоваться осознанно.
Почему вы позволили себе проигнорировать заданные вам вопросы? Если вам нечем на них ответить, можно просто извиниться за свою ошибку.
Конечно, контекст задан статьёй. Просто вы этот контекст игнорируете и начинаете придумывать что-то своё вместо этого контекста.
Касательно таблицы. Вот вы сами пишите, что у вас для таблицы на 100 000 записей и 5 столбцов опера потребляет 1.6 гб. Можно предположить, что если мы возьмём не 5 столбцов, а 16, то есть в 16/5 = 3.2 увеличим объем данных, то у нас и потребление памяти вырастит пропорционально (для простоты) вырастет. Имеем верхнюю оценку в 1.6*3.2 = 5,12 гб. Понятное дело, что скорее всего будет несколько меньше, вот только пользователю у которого всего 5 гб оперативной памяти, большая часть которой уйдёт на обслуживание ОС, легче от этого не станет.
С учётом того, что Опера использует WebKit, как и Chromium и Google Chrome, вызывает интерес, как вы делали замеры. У вас потребление памяти у Оперы и Хрома почти на порядок отличаются. Ведь по вашим словам Опера потребляет 1.6 гб, а Хром всего 180 мб.
Но это все не суть, потому, что вы проигнорировали тот факт, что ячейка таблицы — это компонент, который в свою очередь состоит из html-элементов, которые и идут в DOM-дерево. То есть ваши замеры нужно умножать ещё в 10-15 раз. И это только таблица без всего прочего окружения.
Либо вы забыли уже и то, что писали сами?
Здесь только добавить, что автор не ругал CEO и программистов, которых нанимал сам. Программистов в других филиалах нанимал не я, отвечать за них не мне. Ну и их, я тоже не ругал. Команды разработки платформы (центральный офис, кстати) — да, а вот обычных разработчиков — нет.
Чего ещё добавить. Посыл про «разгребание» тоже не верный. Доработка моего функционала силами моей же команды никаких проблем не вызывала. Это происходило быстро и с заметно более низким количеством ошибок, чем у ребят из соседних филиалов. Проблемы были не у нас, а у тех, кто попробовал это подхватить. Именно они не справились с интенсивностью и нагрузками. Наверное, это они не состоялись, как управленцы?
Кроме того, я же не зря написал, что кроме непосредственно написания кода, и непосредственно руководства одной из команд разработки, я ещё целым филиалом разработки управлял, где моя команда существовала далеко не в единственном числе. Нас много там таких было. Думаю, меня, как управленца характеризует вот этот фрагмент: «...На самом деле, компания теряла только сильного разработчика и, возможно, его команду. В филиале оставалась очень сильная и слаженная команда руководителей. Потом, после того, как решатся проблемы с площадями, эта команда руководителей в неизменном составе отмасштабирует филиал разработки раз в 5. Этим достижением я горжусь…».
Ушёл я потому, что нащупал свой потолок профессионального роста в компании. Дальше только входить в «семью», а для этого желательно обитать в центральном офисе. Плюс политические расклады не позволили маневрировать даже CEO, который ещё и основным владельцем компании был.
Поэтому, я пошёл расти дальше и в другие места. Для бывшего работодателя тоже катастрофы не произошло. На их объемах это был всего лишь маленький укольчик и мелкая неприятность. Там такого и без меня могло периодически происходить.
При моём уходе основная тема переговоров была, чтобы я не трогал команду руководителей, которые все со мной очень хорошо дружили. Деловая этика быстро позволила нам договориться.
Вот только не всегда и не все золотые шестерёнки настолько лояльны к бывшим работодателям. Об этом нельзя забывать.
В целом согласен с вами, но тут ещё более тяжёлая ситуация. Я больше года пытался передать эту экспертизу и знания тем лицам, у кого она должна была быть. Они мастерски уворачивались от вручения этих знаний и экспертизы. Оказывается вручить экспертизу — особый вид искусства.
В какой-то момент мне надоело рассказывать, какие будут последствия, потом пришлось их показать в живую.