RE: Страх и ненависть в IT

    Писать ответы на статьи легко и приятно. Не надо часами корпеть над структурой статьи, достаточно следовать чужому плану и лишь внятно изложить мысли на бумаге. Тем не менее, рискну предположить, что критический взгляд «с другой стороны» на проблемы, поднятые в статье "Страх и ненависть в IT" уважаемым eugene_crabs, все же будет интересен. В роли адвоката дьявола, защищающего бесчеловечную системы выступаю сегодня я.

    image

    Я, в отличии от него, лычек сеньора не ношу, и стаж разработки у меня на пару лет поменьше, да и профильного образования, у меня, если честно, нет. Но вот проблем у меня с базовым интересом к работе не было, и мне кажется — причина в несколько ином восприятии реальности.
    Статья для широкого круга читателей.

    RE: Чрезмерная сложность


    Оригинал раздела
    Когда я занимался железками, мне очень нравилось то свойство, что я насквозь вижу как работает эта штуковина — какие байтики шевелятся, в какой области памяти это происходит и как обошелся с кодом компилятор. Было чувство спокойствия и контроля. Когда чуть позже я перешел в бекенд разработку, я хихикал над бесконечными xmlками конфигураций для EJB или того же спринга. Знал бы я, что меня ждет в будущем. Сейчас я просто не понимаю (и уже отчаялся понять), что происходит внутри моей же несложной приложухи. Куча слоев абстракций, контейнеров в контейнерах, тонны мануалов, скриптов, инструментов, версий, конфиг-файлов. Я до сих пор не разобрался, как деплоится проект, над которым работаю уже полгода. И конечно же нельзя сделать монолит, хотя бы на первом этапе. Обязательно нужно сразу же разделить всё на микросервисы, потому что так правильно (на конференции сказали, что так делают в компании Х). И конечно же мы не можем использовать старый добрый Apache HTTP Client для хождения вооон в тот сервис, который нам нужен 1 раз в несколько минут, ведь этот клиент недостаточно асинхронен, а также в нем нет встроенного рейт лимитера, механизма backpressure и прочих модных штук. На мой вопрос “А зачем это всё нужно для нагрузки 1 запрос/мин?” получаю лишь укоризненный взгляд от коллег, на лбах которых светится надпись “Вот ты тупоооой”.

    Отдельная тема — это господин Джаваскрипт с его бесчисленными фреймворками. Я честно не понимаю, как можно было изобрести СТОЛЬКО штуковин для инструмента, которому нужно просто нарисовать формочки на веб-страницы и время от времени отправлять запрос на бекенд. Хорошо, что я занимаюсь бэкендом.

    На примере фронтенда (да и не только его) хорошо заметно, как мы ходим по кругу: давайте всю логику выполнять на стороне сервера -> а давайте теперь на стороне клиента -> а давайте теперь снова на сервере и так до бесконечности. Давайте фронтенд и бекенд писать на одном языке -> а давайте теперь на разных -> а давайте снова на одном. Давайте сделаем схемы для форматов данных -> схемы только для старпёров -> а не, схемы нужны всё таки. Один мой кореш перепиливает свою опенсорсную библиотеку с yaml на xml, просто потому, что там есть схемы и это очень здорово, когда клепаешь огромный конфиг, а IDE, осведомленная о XSD сама может выполнить за тебя половину работы. Из вышесказанного вытекает следующая проблема

    Безусловно, приятно манипулировать простыми системами. Я понимаю ту магию, когда ты понимаешь, как это работает до мельчайших деталей: когда спускаешься на уровень ассемблера и машинного кода, и когда идешь еще глубже — туда, где процессор представляет собой ряды логических вентилей.

    Текущая ситуация такова, что мейнстримовые разработки и в ПО и в железе процессоров уже очень далеки от кристального понимания того, как это работает, отдельно взятым человеком: процессоры полны генерированной логики, разноуровневого кеша и предсказателей ветвления настолько, что баги в них не то, что не замечаются, а даже не предполагаются целыми командами разработчиков, и цветут настолько буйным цветом, что прорываются в своих эффектах на уровень пользователя. Кроме того, мы вынуждены тащить за собой огромный багаж старых функций, обеспечивая тем самым обратную совместимость, иначе выиграем в скорости и простоте, но проиграем в работе того, под что это железо изначально разрабатывалось.

    С софтом та же ситуация: понимание, и тем более написание ассемблерных инструкций осталось лишь в узко-специализированных областях, а в том, что живет и крутится в непосредственной близости от пользователя, безраздельно царят фреймворки и слои абстракции.

    С точки зрения человека, желающего контролировать свой код и машину — это плохо. С точки зрения пользователя — хорошо, так как упрощает понимание, работы и путь от идеи к продукту. Цена, которую платим мы за это желание пользователей — то, что растущие мощности процессоров тут же сжираются сложностью программ, которая, вроде бы, ничем не обоснована, и не несет никаких плюсов (вэээээлью, как говорили на моем предыдущем месте работы).

    Однако, если копнуть глубже, окажется, что мы меняем эти ресурсы на увеличение аудитории за счет упрощения взаимодействия. Если раньше терминалы заказа авиабилетов требовали знания сокращений, понимания, как работают авиакомпании и навыка работы с текстовым терминалом, то теперь любой пользователь заходит на условный Aviasales, и подбирает себе дешевый билет по сложному маршруту без особого геморроя.

    image

    Нельзя сделать понятный среднему человеку интерфейс на текстовом терминале, потому что понятность интерфейса — это и разрешение монитора, и приятные картинки, которые не пугают мозг, и красивые шрифты, и подсказки, всплывающие при наведении на кнопку, и сенсорный интерфейс.

    А еще, возможность тестировать все эти фишки, ориентируясь на поведение пользователя. Работая по waterfall, вы выкатываете релиз раз в год, собирая отзывы на текущую версию весь год. До какой-то стадии интерфейса вы идете десять лет, десять релизов. Выкатывая мелкие исправления и тестируя их тут же, вы придете к той же стадии через год-полтора. Но такая работы требует другого темпа, других инструментов и технологий, и отказа от некоторых вещей. В честности, от вылизывания кода: все должно работать сейчас, потому что того требует процесс такого темпа.

    Взамен, эта сумасшедшая гонка за новыми фичами дарит нам растущую пользовательскую базу: чем проще нажимаются кнопки, тем больше людей смогут их нажать, а растущая пользовательская база несет деньги не только в ваши зарплаты, но и в разработку нового железа. Чем больше людей смогут продуктивно пользоваться смартфоном, тем больше его купят, тем лучше будет железо в следующей версии. То, что мы тут же размениваем это железо не на полеты на марс, а на растущую аудиторию… ну, это можно сравнить с компанией, которая вкладывает весь заработок в развитие, а не в дивиденды и прибыль в годовом отчете. Только вот вы почему-то оправдываете, когда так делают Маск и Безос, но не можете оправдать индустрию.

    Хорошо это или плохо — можно спорить. С одной стороны качество ПО, с другой — постоянный прогресс в железе, аудитория и большие зарплаты в индустрии. Я, пожалуй, выберу второе (хоть и предпочел бы сбавить темп), но пойму людей, которые выберут первое.
    Но объединит нас одно — мы ничего не сможем с этим сделать.

    RE: Слишком много всего


    Оригинал раздела
    Инструментов, языков, книг, конференций, фреймворков и т.д. Уже давно позади те времена, когда для разработки софта достаточно было знания одного ЯП, пары библиотек и в общем-то и всё. Теперь нас ожидают сотни фреймворков, с десяток языков (даже в рамках одного проекта), модные и не слишком СУБД, вездесущие брокеры сообщений, сотни квадратных километров разложенных граблей и прочего веселья. У среднестатистического программиста как правило нет времени на изучение всего этого на работе (кроме тех инструментов, что уже используются в его проектах), потому что на ней надо работать. Многим приходится тратить личное время на изучение этих технологий, хотя скорее всего 90% из изученного никогда не пригодится. У меня самого в покете лежит полтысячи статей, куча непосмотренных видосов с конференций, а каждый заход на Хабр предвещает обязательный визит Макконахи.

    Но даже плотная работа с определенным ЯП или, к примеру, СУБД в своей компании иногда не дает возможности оставаться в тренде, т.к. технологии устаревают раньше, чем их успевают применять. Даже джава сейчас релизится со скоростью фаерфокса.

    Благодаря бесконечному потоку быстроустаревающих знаний многие из нас чувствуют себя вечными студентами или самозванцами, неважно сколько систем ты реально построил. И это очень на руку HRам и работодателям — ведь легко можно сбить твою ЗП парой заковыристых вопросов. Такой вид крысиных бегов HRы политкорректно называют саморазвитием.

    То, что инструментов много — это логическое продолжение предыдущего пункта. Когда в области много энергии, это позволяет тратить лишнюю энергию на тестирование гипотез, часть из которых окажется провальными, часть засохнет, а вот часть ляжет в основу новых стандартов индустрии. Жалобы на хаос подобны жалобам на неэффективность эволюции, которая зачем-то создала кучу видов, огромная часть из которых тихо вымерла, и еще большая часть не очень успешна, и прозябает в узком ареале. Неужели нельзя было сразу создать человека, который может выжить хоть на северном полюсе, хоть в пустыне, несмотря на то, что сам довольно хилый — бегает небыстро, когтей нет, зубы маленькие и тупые, угол обзора небольшой.

    На результат эволюции хорошо смотреть со стороны, и удивляться про себя, какой долгий путь потребовался для создания вполне очевидного преимущества — гибких пальцем и развитого мозга.

    Но вот в самом начале пути результат был совсем не так однозначен: динозавры-то тоже когда-то царили на земле безраздельно, и живи биржевые аналитики в их времена, мало бы кто поставил на каких-то млекопитающих крысок против этого явного фаворита.

    Отходы в виде «неправильных» инструментов — это постоянный спутник того пути, что ведет на вершину.

    RE: Программист должен быть бизнес-аналитиком & Собеседования


    Оригинал раздела
    В последнее время я наблюдаю тренд навязывания разработчикам полномочий бизнес-департамента. Теперь помимо выполнения своих основных задач, разраб обязан разбираться в предметке на уровне хорошего аналитика и вообще думать про бизнес. Отстаньте от меня, я не знаю как повысить вашу конверсию.

    Собеседования

    Это самый важный и горячо любимый мною вид спецдисциплины. Ведь по факту именно от этого зависит будешь ли ты спать на старом продавленном диване в арендованой однушке где-то за МКАДом, или же придется укрываться картонкой лежа на теплотрассе под мостом. Если в начале моей карьеры собеседование было чем-то типа разговора по-душам, то сейчас это больше напоминает экзамен. Возможно это связано с тем, что в те времена не было таких огромных зарплат и толп желающих войти в айти или просто мода, я не знаю. Но факт в том, что придя на собеседование на позицию старшего разраба, с огромной долей вероятности ты столкнешься с задачками, приправлеными вопросами-викториной. “Ну-ка реши на бумажке задачку, которую мы вчера стащили с leetcode. Ошибся на единичку в граничном условии? Фууууу лох! Не знаешь, как работает %methodName% в моднейшем %frameworkName%. Кто его вообще сюда пустил? Охрана!” Никого больше не волнует, что твоя голова устроена по-другому и ты не можешь в стрессе под презрительно-снисходительным взглядом высоколобых ботанов быстро и без ошибок наваять алгоритм под задачу, над которой ты и подумать ещё не успел. Как и то сколько за твоей спиной километров кода и продакшон-систем. Хорошо хоть вопросы-головоломки сдохли, и на том спасибо.

    Да нет, не должен конечно. Но в условиях необходимости быстрой проверки гипотез, гораздо продуктивнее это делать в той же голове, которая принимает решения о архитектуре, просто потому что накладных расходов меньше: надо не два дня совещаться, а час подумать. Умеете в предметную область — молодец, спи на продавленном диване. Не умеешь — тебя ждут в тех областях, где надежность важнее прогресса: космос, медицина, военка, системы сигнальной связи. Эти области есть, и они ничуть не менее важны фронтенда. Правда, платят меньше. Такой уж перекос на рынке, который бы и я бы хотел исправить, но это нечто, что выше не только человека, но и большинства компаний.

    Кстати, этот же фактор позволяет несколько свысока посматривать на HR с заковыристыми вопросами, вплоть до «не знаю я, чего пристали, давайте уже с техдиром пообщаемся». Не хотите быть аналитиком, а хотите писать код по готовому вылизанному ТЗ? См. выше — другие области для вас: хорошие программисты, не делающие ошибок и качественно и грамотно реализующие ТЗ тоже очень нужны.

    RE: Айтишники


    Оригинал раздела
    Тут разберем несколько подвидов этой популяции, с которыми чаще всего приходится иметь дело.

    Собственно разработчики и сочувствующие. Вопреки стереотипам — в большинстве своём не ортодоксальные ботаны, а вполне себе нормальные ребята. Вот только как правило говорить с ними не о чем. Все разговоры во внерабочее время сводятся к работе. А как иначе, если ты вынужден круглосуточно вызубривать всю эту техномуть? Мой совет — держитесь подальше от ребят в клетчатых рубашках с рюкзаками, иначе можете заработать летальную дозу скуки. Многие из них ходят на работу не работать, а играть в игрушки. Давайте изобретем велосипед, давайте прикрутим новый фреймворк (и будем по ночам разгребать ад на проде) и непременно бросим всё на полпути, потому что эта игрушка надоела, к тому же новые завезли. Зато потом будем дуть щеки и рассказывать на конференциях, как мы победили проблему, которую сами же и создали. PROFIT! Эти люди так же легко ведутся на всякую чушь типа “интересных задач” и “сложных систем” (в айти культ сложных систем, поэтому калькулятор без десятка микросервисов сейчас построить нельзя), что в переводе на человеческий означает ковыряние в прокисшем дерьме мамонта, но за меньшие деньги, тем самым снижая ЗП по отрасли. Как в анекдоте “- Папа, а что мы сегодня будем кушать? — Ничего, сынок, я работаю над интересными задачами в дружном коллективе.”

    Проджект-менеджеры. Честно говоря, за 10 лет я так и не понял кто такие проджект-манагеры и зачем они нужны. В совершенно разных конторах это выглядело примерно так: вот там пачка задач, разберитесь чего там и как и вот до такого-то числа сделайте. А я пошел возьму латте у хипстеров на первом этаже и напишу в инстаграме какой сегодня тяжелый день. Только однажды я видал чувака, который строил все эти скучные графики, жонглировал задачами и был нашим помощником, а не просто классным парнем, который не смог в программирование, но айтишную ЗП очень хочется.

    Вайтишники. Нежно любимая многими категория. Благодаря их демпингу толковые и идейные джуны не могут въехать в индустрию — в погоне за длинным рублем, многие вкатывальщики готовы работать вообще бесплатно.

    Про остальных умолчим.

    Скучные разработчики, которые говорят только о работе? Странно, мне кажутся скучными те, кто хочет спокойно пилить код по готовому ТЗ с 9 до 18. Мы оба не правы, но я немного о другом: такая организация ума, при которой задача крутится в голове постоянно, дает весомый буст к скорости разработки и проверки гипотез. Чуть за грань, и там маячит выгорание, но это вопрос контроля ментального здоровья. Что не отменяет того факта, что некоторые компании (не будем показывать пальцем на тех, кто оплачивает сотрудникам такси после 22 часов, стимулируя задерживаться на работе) поняв, что горящий сотрудник работает лучше, предоставляют все условия для этого горения.

    Проджекты? Вы просто не умеете их готовить. Проджект — это универсальный инструмент: с одной стороны, он берет на себя волшебные пинки для программистов (программист, предоставленный сам себе, переключается на производство приколюх для себя любимого), а с другой стороны, архитекторы и тимлиды могут сбрасывать на него львиную долю организаторской работы по организации встреч, поддержании актуальности графика, отчетам о проделанной работы, рутинной коммуникации с заказчиком и так далее.

    RE: Бизнес


    Оригинал раздела
    Софт в современном мире не делается просто потому, что это прикольно (хотя иногда так кажется). Он делается чаще всего для зарабатывания бабок — прямо или опосредованно. И в связи с этим фактом можно разделить людей на 2 категории.

    Тем кому важно как — чтобы внутри было всё красиво и правильно.

    Тем кому важно что — те люди, которым важна суть продукта, который они делают.

    Обычно в разработчике содержатся обе эти категории, просто в разных пропорциях.

    Для обоих из них у меня есть печальные новости.

    Для первой категории — с точки зрения зарабатывания денег абсолютно неважно насколько правильная архитектура выбрана и насколько красив код. Точно так же как и на всю эту вашу безопасность, лучшие практики, etc. Можно навтыкать костылей, заработать бабок, а дальше тот манагер, который всё это учинил спрыгивает на соседнюю шлюпку “получать новый опыт”, а команда ночами разгребает конюшни.

    Для второй категории — 90% из вас делает то, что уже давно сделано другими. За редким исключением, все ваши продукты глубоко вторичны. Но тем не менее, ушлые дельцы пытаются придать “идейность” очередной платежной системе, онлайн-банку и тому подобному. Я сам все это проходил, и надо сказать, гораздо легче работать, когда у тебя есть четкий ответ на вопрос “зачем всё это нужно”. Все эти “менятели” мира почему-то забывают сказать, что изменение мира происходит как побочный результат зарабатывания денег, а не наоборот. Тяжело менять мир, когда к твоему виску приставлено дуло дробовика совета директоров, а на шею накинута удавка акционеров. Как по мне фраза “мы работаем для того, чтобы заработать денег” звучит гораздо честнее. Другое дело, что если сейчас сказать HRу, что ты работаешь на работе за деньги, то 146% получишь в ответ недоуменный взгляд и что-то типа “Вы нам не подходите, нам нужны увлеченные люди, которым важны саморазвитие и интересные задачи”.

    Так уж случилось, что человек придумал деньги. Сделали это не в текущем поколении, и даже не сто лет назад. Деньги показали себя отличным инструментов для организации разнородного общества с разными понятиями о прекрасном и разными желаниями входящих в него людей.

    Вы можете попробовать изобрести что-то другое, но пока что-то ничего кардинально лучше не придумали. Есть, конечно, мотивация типа социальной поддержки и командного духа, но первая — производная от денег, которые переварило государство, а второе — приправа, а не основное блюдо. В крайнем случае, десерт.

    За вашу работу вам платят деньги. Если ваша работа не приносит денег — простите, она не нужна бизнесу. Грубо, знаю. Давайте попробуем мягче.

    Бизнесу нужны деньги. Бизнес — это организация, которая зарабатывает деньги. Если вам не дают денег на то, что вы считаете нужным — значит, вы не показали, как эта штука принесет бизнесу еще больше денег. Научитесь обосновывать трату ресурсов, докажите, что это приносит пользу, пусть даже долгосрочную, и ресурсы будут. Бизнес и ЛПР бизнесу в этом плане гораздо адекватнее среднего человека, правда: там где человек будет жаться купить проездной на пол-года за десять тысяч, потому что это так много денег, и предпочтет покупать каждый месяц проездной за две тысячи, бизнеса интересует лишь одна цифра — прибыль на вложенные деньги. 16% прибыли? Берем! Нет денег, но можно взять кредит на эту траты за 5%? Берем!

    Если в некой компании не удается обосновать ревью кода, потому что их код живет три месяца, после чего заменяется новым, то бегите оттуда, что вы там делаете? Есть огромное количество компаний, для которых ревью кода и рефакторинг — важные компоненты процесса. А первая компания сосредоточена на проверке гипотез, а не на кодинге: это тоже нормально, и позволяет найти новую нишу, в которой можно вырасти, заматереть, накопить жирок и начать практиковать ревью и рефакторинг.

    Не стоит осуждать дизайнера, который строит домик из игрушечных кирпичей, не скрепляя их раствором: жить в этом домике хомячку, и задача этого дома — протестировать гипотезу внешнего вида, а не служить домом. И даже если этот дизайнер готов платить вам за то, что вы помогаете ему строить его игрушечный домик, не брызгайте на него слюной на то, что нужен раствор и котлован, а устройтесь в нормальные строители.

    RE: Здоровье


    Оригинал раздела
    Каждый знает, что если долго поднимать тяжести, то без должной подготовки (или даже с ней) гарантировано получишь проблемы со спиной и суставами. То же самое можно сказать про мозг, только это менее очевидно. Наша работа требует высокой отдачи и концентрации, даже если мы всего-лишь рефачим тесты на автомате, слушая в фоне очередной разведопрос. Мне кажется, что мозг просто не предназначен для таких ежедневных подвигов. Я работал на разных дерьмовых работах, в том числе физических и могу сказать, что я нигде не чувствовал себя настолько выжатым и разбитым, как выходя каждый день из офиса. Многие мои коллеги 35+ чувствуют примерно тоже самое, а на форумах начали появляться вопросы “Что делать, если тебе 25 и ты выгорел?” или “Как выйти из айти?”. Как долго удастся протянуть в таком режиме — вопрос интересный.

    Пожалуй, это единственный пункт, на который мне нечего полноценно ответить. Кроме того, что в моем мире человек обладает волей и разумом, и если считает, что ему не надо поднимать тяжести, то он не будет их поднимать.
    Поддержать автора
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 49

      +4
      Кроме того, что в моем мире человек обладает волей и разумом, и если считает, что ему не надо поднимать тяжести, то он не будет их поднимать.

      Сломав или просто поцарапав руку — ты умеренно здраво(когда адреналин сойдёт) оцениваешь состояние и принимаешь решение лечить.
      Здоровье же мозга не в последнюю очередь влияет на способность этого самого мозга оценивать собственное здоровье. И, соответственно, вовремя видеть начало входа в и здраво принимать решения по выходу из — что и мешает "но это вопрос контроля ментального здоровья" без наличия опыта. Да и при наличии непросто.
      Особенно когда горение ещё и поощрается, а негорение открыто ставится минусом.
      Ну и плюс стигматизация/убеждение "я не псих же, ко всяким копающимся в голове ходить!"/"выдумка это всё, прорвёмся"/"пахать надо больше, не будет времени на глупости".

        –3
        Про здоровье мозга вы, мне кажется, преувеличиваете: повредиться разумом от выгорания до такой степени, чтобы не заметить этого самого выгорания… Вряд ли.
        По поводу же всего остального — у многих профессий существуют профессиональные заболевания. В куче из этих профессий для их предотвращения ничего не делается, и даже поощряется. Ну, вот и в IT теперь, помимо туннельного синдрома еще и это. Так себе ситуация, но не мы первые и не мы последние.
          0

          Заметить то можно. Вот с поиском выхода всё куда хуже, потому что мозг к этому моменту уже несколько заклинен в сложившейся ситуации.
          И это если понимать, что именно следует замечать — а вокруг звучат убеждения вплоть до "выгорание выдумали лентяи" и "заведи семью, возьми ипотеку, родите ребёнка — и как рукой выгорание снимет!". Звучало на Хабре буквально недавно в каких-то из близких к выгоранию тем; да и в просто жизни встречалось

            +1

            Профессиональное выгорание существовало задолго до ИТ. И методы борьбы с этими явлением давно известны.

            +3
            Про здоровье мозга вы, мне кажется, преувеличиваете: повредиться разумом от выгорания до такой степени, чтобы не заметить этого самого выгорания… Вряд ли.

            Экий у вас идеальный мир с летающими понями…
            Повредиться разумом человек может безо всяких выгораний. Просто «повреждения» бывают сильно разные, и вовсе не обязательно человека в психушку увозят. Бывают просто граждане с очень специфичными завихрениями в картине мира. Причем у кого-то эти завихрения так и остаются милыми безобидными завихрениями, а кто-то начинает бункер рыть в подвале многоэтажки, спасаясь от рептилоидов.

            Что касается «не получится не заметить» — вы сильно, ну прямо вот вообще очень сильно, недооцениваете защитные механизмы мозга. Во-первых, «съезжание крыши» происходит постепенно, и человек так же постепенно обрастает защитными «коленными рефлексами» при столкновениях с суровой реальностью. Во-вторых, людям и в нормальных-то обстоятельствах бывает трудно оценить свое поведение со стороны, а представьте, каково человеку, которого окружают агенты инопланетян, успешно маскирующиеся под людей…
          +10
          Обычно Вас интересно читать.

          С одной стороны я понимаю Вашу точку зрения и частично ее разделяю. Есть что есть и оно даже работает.

          С другой стороны — программирование это не производство. Как бы не пытались его зделать производством.

          Программирование это управление сложностью. И мы продвигаемся в этом направлении. Но ключевая проблема остается без внимания. Количество слоев обстракции растет експоненцияально и у нас нет ничего (ни инструментов, ни методик) чтобы ими управлять. Не отдельно взятыми абстракциями — а всей стопкой.

          И рано или поздно эта стопка пройдет какой-то критический размер и сколлапсирует. И нам всем прийдется это разгребать.

          ИМХО то что интел не может починить свою безопастность — первые ласточки. По слухам там еще несколько дыр еще не опубликованных. Возможно именно по безопастности и произойдет взрыв. Мы, как программисты, знаем что взломать можно абсолютно все. Но рано или поздно это поймет большинство. А за ними, что хуже, политики. И вот тогда ситуация полностью уйдет из под нашего контроля.
            –2
            Количество слоев обстракции растет експоненцияально и у нас нет ничего (ни инструментов, ни методик) чтобы ими управлять.
            Мне кажется есть — стандартизация. Но пока ещё не наигрались в фиолетовые кнопочки.
            Мы, как программисты, знаем что взломать можно абсолютно все.
            Как хакеры — с натяжкой, как программисты — спорное утверждение. Как программисты — мы знаем что пишем так что можно сломать.
            И вот тогда ситуация полностью уйдет из под нашего контроля.
            Из под какого контроля? Какой у программиста контроль? Контроль писать так что можно сломать?
              +1
              > Мне кажется есть — стандартизация

              она касается только одного слоя абстракциии. В лучшем случае между двумя абстракциями.

              > Как хакеры — с натяжкой, как программисты — спорное утверждение

              не умеем, а знаем.

              > Какой у программиста контроль?

              Никакого. А вот у профсоюзов или коммитетов (хз как перевести bar в данном контекста) уже не мало.
                0
                на касается только одного слоя абстракциии. В лучшем случае между двумя абстракциями.
                Вам конечно виднее, но если присмотритесь поближе к инженерным решениям и областям деятельности, сразу увидете причины для этого.

                Одни программисты кто в лес, кто по дрова. Это пословица какая-то получается
                Плохому программисту «абстракции» мешают.
                Потому что еще не выросли из детских штанишек. Всё ещё в стадии ремесленников, а не инженеров.
                не умеем, а знаем
                На ленте.ру прочитали что «взломать можно абсолютно все»? Или «знаем», но «не умеем»? Детский лепет какой-то.
                Никакого. А вот у профсоюзов или коммитетов (хз как перевести bar в данном контекста) уже не мало.
                Вы профсоюзный деятель? Вы писали «ситуация полностью уйдет из под нашего контроля». Тогда «вашего» правильно получается.

                Программист состоящий в профсоюзе — сейчас это нонсенс. Только если работает в компании в которой есть общий профсоюзный договор. Профессиям с более-менее высокими интелектуальными требованиями и высоким входным порогом, нету экономических причин для создания профсоюзов. Это не про программистов, а вообще обо всех. Не то что я против профсоюзов, но такова реальность.
                  0
                  > Вам конечно виднее,… сразу увидете причины для этого

                  погодите. Я не критикую стандартизацию и не говорю что она не нужна. Я говорю что она принципиально не подходит для управлением количеством слоев абстракции.

                  > Плохому программисту «абстракции» мешают.

                  где вы нашли этот бред? Я такого не мог написать нигде и никогда.

                  > Детский лепет какой-то.

                  безопастники на моих проектах почему-то находят дыры, а не рассказывают что «могут».

                  > Программист состоящий в профсоюзе

                  Вы пишите в разрезе зарплат. Я писал про другой разрез.
                    0
                    Я говорю что она принципиально не подходит для управлением количеством слоев абстракции.
                    Поясните в чем она принципиально не подходит, а то не очень понятно ваше утверждение.
                    безопастники на моих проектах почему-то находят дыры, а не рассказывают что «могут»
                    Это характеризует ваши проекты, но когда делается глобальное утверждение «абсолютно все» — это должно базироваться на нечто большим, чем пример с вашими проектами. И да, безопасник — это не программист.
                    Вы пишите в разрезе зарплат. Я писал про другой разрез.
                    Если вы имеете в виду сертификацию, по подобию той что существует в некоторых странах на профессии типа врач, юрист, инженер и даже простой электрик, то это повышает входной порог, но никого не останавливает. Просто ещё один шаг — сделал и забыл.

                    Ну может придётся купить страховку, чтобы покрыть риски допушенной ошибки, если будет персональная ответсвенность, как у врачей. Но как это относится к какому-то «контролю над ситуацией»?
              +1

              Вообще говоря подходы к написанию надежного кода практикуются ещё со времён первых Шаттлов. Другое дело что большинству менеджеров пока важнее добавлять свистелки.

                +1
                > Вообще говоря подходы к написанию надежного кода практикуются ещё со времён первых Шаттлов.

                При всем при этом условия изменились. Создатели первых шатлов разрабатывали все слои абстракции начиная с железа и заканчивая психологией пользователя.

                Как бы мы не ругали скупость создателей машин и самолетов — я сомневаюсь что они вообще могут написать весь необходимый код на том же уровне. Как минимум — у них там уже несколько операционок.
                  0

                  В современной винде строк кода примерно на порядок больше, чем в прошивке Шаттла. С другой стороны, команда разработки софта там была небольшой, а инструменты — гораздо менее удобными, чем современные. Кроме того, добавление фич зачастую идёт по принципу «лишь бы было», вместо улучшения надёжности, стабильности и быстродействия — при том, что большинству пользователей хватает и Windows 7 с Word 2003.

                  0
                  Вообще говоря подходы к написанию надежного кода практикуются ещё со времён первых Шаттлов. Другое дело что большинству менеджеров пока важнее добавлять свистелки.
                  Проблема не в свистелках и менеджерах, проблема в том, что разработка с учетом техник «безопасного кодирования» и всего что вокруг этого (типа верификации, сертификации) в итоге выходит очень дорого по деньгам. А большинство покупателей, увы, голосует рублём (точнее, долларом), и часто не готово платить в 10 раз дороже за «надежность» и «безопасность».
                    0

                    Рентабельность IT компаний чересчур завышена: если бы были регуляции, обязывающие всё тщательно проверять, то им бы просто пришлось поумерить аппетиты — конкуренция-то никуда не денется. А высокая рентабельность и триллионные капитализации образуются в том числе за счёт того, что IT компании привыкли перекладывать издержки-экстерналии, образующиеся из-за использования глючного, медленного и уязвимого ПО, на конечных пользователей: всех как-то приучили, что если ты поймал вирус — «сам виноват«, если тормозит система — «купи новое железо», упала система — «просто переустанови её», накатил обновление, из-за которого перестал работать критичный софт — «сам дурак, надо было проверить на виртуалке» и тп.

                  0
                  И рано или поздно эта стопка пройдет какой-то критический размер и сколлапсирует. И нам всем придётся это разгребать.

                  Ну, возможно. Это обычный процесс и ничего с ним нельзя сделать, рост-кризис-изменение-рост.
                  Ну, например, динозавры. Вырастив огромных существ на доступных ресурсах, эволюция зашла в тупик: дальше изменяться некуда, для более высокой высоты надо спуститься с текущей горки, а зачем это делать, если пока норм. А когда стало не норм — шанс получили другие классы существ, и оказалось, что теплокровные млекопитающие более эффективные: стабильная температура позволила поднять тактовую частоту мозга и остальных систем, быстрый метаболизм позволил выделить на мозг достаточно энергии, чтобы эффект от мышления начал приносить качественно новую пользу.
                    0
                    А когда стало не норм — шанс получили другие классы существ, и оказалось, что теплокровные млекопитающие более эффективные: стабильная температура позволила поднять тактовую частоту мозга и остальных систем, быстрый метаболизм позволил выделить на мозг достаточно энергии, чтобы эффект от мышления начал приносить качественно новую пользу.
                    Так сейчас вроде же как считают, что таки у них была стабильная температура и весьма высокий метаболизм.
                      0
                      Ну, значит что-то другое сыграло роль. Я скорее про то, что качественно иной рост зачастую прекрасно развивается на обломках старого мира.
                      0
                      Спасибо что ответили.

                      Вы сейчас пишити с точки зрения наших потомков. «Век назад програмисты были не сильно умны и не видили этой очевидной проблемы. Эта проблема разрослась до размеров коллапса и теперь мы знаем что нужно ...»

                      Я пишу с точки зрения того, кто почти наверняка этот кризис будут непосредственно переживать. Как и Вы. Зачем мне массовые увольнения по всей индустрии и резкое падение зарплат во всем мире?
                    +2
                    Если раньше терминалы заказа авиабилетов требовали знания сокращений, понимания, как работают авиакомпании и навыка работы с текстовым терминалом, то теперь любой пользователь заходит на условный Aviasales

                    То есть гигабайты фреймворков сейчас уходят на то, чтобы пользователь мог тыкать кнопочки и менюшки на сайтах? Но позвольте: кнопочки и менюшки ничем принципиально не изменились с 80х годов, когда графические ОС умещались на паре-тройке дискет.

                      0

                      Ну как же не изменились — стали круглее, чтобы бедный юзверь не порезался глазами об острые углы; цветастее, чтобы ему не приходилось напрягать межушный ганглий для чтения надписей; крупнее, чтобы ему не приходилось целиться для нажатия.
                      А так как больше всего денег приносят именно юзвери, не умеющие в чтение, прицеливание и боящиеся острых углов, в силу своей банальной численности, то это и пользуется спросом.

                        +3
                        Ваше пренебрежение к юзерам, которые не хотят пользоваться плохими интерфейсами мне непонятно: без них у нас бы до сих пор были менфреймы, дисплеи 80х70 и программы на фортране или си.
                          0
                          менфреймы, дисплеи 80х70 и программы на фортране или си.


                          image
                          prnt.sc/q7cjsz

                          Дату видите?
                            0
                            Эм. Я вам могу и перфокарты использующиеся найти. Только это не отменяет того, что вы читаете этот сайт с LCD-экрана с 32-битным цветом и разрешением, которое не очень давно никому даже не снилось. И хорошо, если это разрешение экрана не телефона, который вы держите в руке.
                          –1
                          А так как больше всего денег приносят именно юзвери, не умеющие в чтение, прицеливание и боящиеся острых углов, в силу своей банальной численности


                          С учетом того, что процентов 70 капиталов планеты принадлежит 5% населения это кажется сомнительным.
                            0

                            Им принадлежит столько денег как раз потому, что они не приносят их кому-то другому :)

                              0
                              Наличие денег не означает, что кто-то готов платить больше за тот же функционал.
                                0
                                Зато наценку им выкатить проще, чем тем, кто последний хрен без соли доедает. Или я не прав?
                                  0
                                  Да нет, если вы не монополист или не можете предложить какие-то дополнительные услуги.
                          +2
                          Неужели нельзя было сразу создать человека, который может выжить хоть на северном полюсе, хоть в пустыне, несмотря на то, что сам довольно хилый — бегает небыстро, когтей нет, зубы маленькие и тупые, угол обзора небольшой.

                          Не очень удачный пример. Намного убедительнее в плане выживаемости смотрелась бы тихоходка
                            +3

                            Забавно, что первоначально, автор сетует на то, что программирование из инженерной профессии превратилось в какую-то маркетинговую машину по зарабатыванию денег. Вы на протяжении всей статьи, в сущности, подтверждаете его точку зрения и вся разница в том, что вы говорите: "да, так и надо".


                            Не буду утверждать, кто из вас прав, а кто нет, мне просто ближе точка зрения автора оригинальной статьи. Мне кажется забавным тот факт, что программирование — единственная "инженерная" область, в которой техническое совершенство не является конкурентным преимуществом.


                            Если взять какие-нибудь "обычные" инженерные вещи вроде автомобилестроения или даже обычного строительства, то можно увидеть, что работа над техническим совершенством частей составляющих "продукт" (автомобиль, строительство, производство ЦПУ etc) приводит к улучшению конкурентоспособности "продукта" (сниженное потребление бензина, более долговечные конструкции зданий, сниженное энергопотребление). Такое положение вещей приводит к тому, что цели инженеров (делать крутые штуки и улучшать мир) и бизнеса (извлекать прибыль) совпадают.


                            В программировании наблюдается какой-то обратный процесс. Херачим говнокод, с говнокостылями, приправим электроном и вот у нас чатик размером гигабайт (привет Slack). Получается, что интересы программистов (писать "хорошие" стабильные системы) и интересы бизнеса расходятся в корне.


                            Интересно и то, что судя по тем книгам что я читал (мне почти 27, я не застал начало эпохи программирования, пришлось читать об эпохе 80-х из книг), такая ситуация была не всегда. Во времена ограниченных ресурсов, программисты занимались тем, чем и должны — повышали технологическое совершенство софта. А потом началось, где-то в начале двухтысячных началась "hardware лихорадка". Нам (программистам) дали слишком много ресурсов и мы всё просрали. Просто мы не успели придумать, чем бы это железо нагрузить.


                            Бизнесы еще не успели осознать какие объемы данных можно теперь обрабатывать, поэтому появились х**яторы, которые решили задачи бизнеса самым дубовым способом — и это работало, потому что железо вывозило. С тех пор, мы разгребаем последствия :)

                              +2
                              Получается, что интересы программистов (писать «хорошие» стабильные системы) и интересы бизнеса расходятся в корне


                              Нет, не расходятся. Точнее, вы неправильно понимаете интересы программстов.

                              Большой процент программистов выдаёт на-гора плохо написанный говнокод, потому что другого не умеет и уметь особо не хочет (у меня вот хит месяца — вместо одной функции на 30 строк с тремя параметрами человек нагенерировал десяток функций и 300+ строк копипастом, захардкодив эти параметры во всех практически возможных комбинациях. Следующим шагом, разумеется, нашёл ошибку, в половине копипасты её исправил, в другой забыл. Вы думаете, зелёный джун? Нет, десять лет опыта, профессиональный разработчик встраиваемого ПО для серьёзной промышленной автоматики).

                              Бизнес этих программистов нанимает, во-первых, потому, что других тупо мало, во-вторых, потому, что оценить качество кода постороннему человеку намного сложнее, чем качество автомобиля — а до состояния «у меня работает» программисты свои поделия доводить таки научились.

                              При этом такие вещи, как QA, code review и т.п., по сути внедрены как раз бизнесом. И вот здесь интересы бизнеса и программистов действительно расходятся ;)
                                0
                                А код с захардкоженными параметрами не работает быстрее в некоторых случаях? Иногда даже разворачивание цикла быстрее работает.
                                А ошибки копипасты везде бывают, нужно проверять внимательнее…
                                  +1
                                  Конкретно этот код — это вывод на графический монохромный ЖК по SPI, случающийся раз в секунду. Плюс-минус десять микросекунд в его производительности не волновали ровным счётом никого, а вот минус триста строк кода, минус три килобайта прошивки и минус все ошибки копипасты разом после сведения этой простыни к вызову одной функции с тремя параметрами — многих.
                                0
                                Такое положение вещей приводит к тому, что цели инженеров (делать крутые штуки и улучшать мир) и бизнеса (извлекать прибыль) совпадают.

                                Получается, что интересы программистов (писать «хорошие» стабильные системы) и интересы бизнеса расходятся в корне.


                                Цели работника и бизнеса совпадают! Цель бизнеса — получение максимальной прибыли при минимизации издержек. Цель работника точно такая же — получение максимальной прибыли (зарплаты) при минимизации издержек (усилия, рабочее время, и т.д.).
                                Просто в других отраслях уже давно дошли до того, что надо как то контроллировать процесс производства и качество конечной продукции. Или бить рублем, если не хотят по хорошему.
                                Представьте себе, что приходится жить в доме, в котором постоянно течет крыша, ветер задувает в щели в стенах, свет может сам по себе выключиться в любой момент и неизвестно когда включится. И это продолжается изо дня в день, хотя каждый день приходит мастер и исправляет, исправляет, исправляет. А как насчет автомобиля, который после каждого технического обслуживания начинает ехать на 10% медленнее, но при этом начинает потреблять на 10% больше бензина. Зато в последнее ТО появилась симпатичная подсветка приборной панели, а фары теперь мигают при виде хозяина. Но надо отдать должное, в предыдущее ТО наконец стала закрываться водительская дверь, хоть это и не работало с завода. Но теперь не окрывается багажник. Но это естественный процесс, мы работаем над этим, пользователю надо немного потерпеть. И вообще, есть же лицензионное соглашение, где мы снимаем с себя всю ответственность.
                                0

                                (Упс, промахнулся. Это ответ MooNDeaR на комментарий выше.)


                                [с "обычными" инженерными вещами] работа над техническим совершенством частей составляющих "продукт" [...] приводит к улучшению конкурентоспособности "продукта"

                                Не совсем. Дело в том, что для «обычных» вещей фаза производства экземляра имеет вполне себе существенную стоимость, а затраты по эксплуатации этого экземпляра перекладываются на покупателя. В случае с программным обеспечением же затраты на производство экзепляра околонулевые, большая часть расходов вызвана по сути конструкторской деятельностью. Кроме того, с программным обеспечением очень популярен подход, когда прямые затраты по эксплуатации несёт не конечный покупатель — подход software as a service. Поэтому динамика у софта и автомобилей немного отличается.


                                Если инженер-проектировщик автомобиля захочет использовать какую-то технически крутую деталь, которая улучшит мир (например, волшебный поглотитель свинцовых выбросов), но это увеличит стоимость производства и потребует значительных капитальных вложений, то бизнес его вряд ли за это наградит. В то же время, эксплуатационные расходы в какой-то мере можно поднимать, если это снизит издержки производства — до тех пор, пока владельцы автомобилей согласны платить из своего кармана за удобство для бизнеса и развитие инженеров, которые получают возможность стремиться к техническому совершенству, не особо оглядываясь.


                                В случае с программным обеспечением решения инженеров слабо влияют на собственно производство, а современные системы делают эксплуатацию сравнительно дешёвой (можно писать слек, жрущий гигабайты, потому что пользователи терпят). Поэтому бизнес волнуют расходы в единственном месте, которое их генерирует — на этапах проектирования и конструирования, во многом состоящих из творчества, где технически крутые штуки очень соблазнительны для инженеров. А замена уже спроектированных и работающих, но менее крутых штух обходится в копеечку для бизнеса, который собственно заказывает музыку.

                                  0
                                  С автомобилестроением легковым особенно ситуация даже хуже, там инженеров заставляют делать всё плохо — заранее вкладывать неизбежные поломки. На рынке уже нет моторов которые могут проехать дольше 150ткм без капиталки ))))
                                  –1
                                  До чего ж обидно быть Вайтишником)) что ни статься, то — камень в огород по поводу демпинга( что, кстати, таки правда, тк сам — презренный ватишник по началу готовый работать за еду0). Ну а в плане разнообразия технологий, тоя согласен с автором, что сейчас мы на первобытном уровне в плане ПО и идет естественный отбор в плане технологий. Через лет 20-50 все будем смеяться по поводу «лучших практик» нашего времени))
                                    0
                                    До чего ж обидно быть Вайтишником)) что ни статься, то — камень в огород по поводу демпинга
                                    Иронично, что на хабре регулярно проскакивают эмоции вроде «да я уже на втором курсе вкалывал в конторке за еду и опыт». Но еще более иронично, что приличный процент комментаторов работает на фрилансе, ругая вкалывающих за еду индусов, и в тоже время демпингуя относительно американских\английских разработчиков.
                                    0
                                    Если честно, меня самого посетила мысль «хайпнуть» на антипосте. Ну, а так если честно, то складно получилось. Спасибо! +
                                      0
                                      >… теперь любой пользователь заходит на условный Aviasales, и подбирает себе дешевый билет по сложному маршруту без особого геморроя.

                                      Странный аргумент, налицо ведь не ограничения технологической платформы, а недоработка в части UI/UX. При желании можно сделать чисто текстовый интерфейс выбора билетов, сверхминималистичный и основанный на диалогах.

                                        0
                                        Это именно ограничение технологической платформы: для человекопонятного интерфейса на диалогах он должен быть похож на общение с человеком.
                                        Это значит языки, правильные склонения, подсказки, умение повторять три раза одно и то же и подсвечивать явные ошибки, например, когда прилет раньше вылета, а разница между рейсами на пересадке всего час.
                                        Значит, много памяти, много логики, UTF-8, строки и примитивы работы со строками, легкость написания и изучения ЯП (потому что проще взять выпускника вуза и научить его писать бизнес-код, чем отдавать программиста в вуз) и так далее. Значит, какой-нибудь питон. А питон невозможен без быстрых процессоров и оверхеда по памяти.
                                        Нет, конечно, можно написать такую логику и на С/ASM, но это настолько сложно и дорого, что выгоднее написать минималистичную систему и посадить девочек-операторов, отдав часть бизнес-логики им в мозг.
                                        Как только цена разработки каждого уровня человекопонятности интерфейса падает достаточно, этот уровень пишут, не особо обращая внимание на костыли и конкретные проблемы подхода и языка. Просто потому, что это дает аудиторию и буст к разработке.
                                          0
                                          Существует огромная разница между читабельностью и бесполезными фичами. Какой-нибудь drop-down на три стандартных опции, обновляющиеся раз в пятилетку, раньше грузился на рефреше, теперь вкорячен на JS/JQ, с асинхронной загрузкой трёх опций из (!!!) датабазы. Я бы понял многоязычность, но её там не росло.
                                        –3
                                        Если ваша работа не приносит денег — простите, она не нужна бизнесу

                                        Всегда было интересно сколько денег бизнесу приносит уборщица. Или бухгалтерия.
                                        бизнеса интересует лишь одна цифра — прибыль на вложенные деньги.

                                        Сколько прибыли Абрамовичу принесла его знаменитая яхта?
                                          +3
                                          Всегда было интересно сколько денег бизнесу приносит уборщица. Или бухгалтерия.

                                          Уборщица приносит бизнесу ровно столько денег, сколько у него станет меньше после того, как половина разработчиков уйдет из-за грязи на полу и необходимости выкидывать мусор, а клиенты будут осторожнее заключать договора в кабинете, в котором немного пахнет несвежим мусором. Много она денег приносит, в общем. Но из-за того, что убираться просто, и квалификации это занятие не требует, зарплаты уборщиц относительно разработчиков маленькие.
                                          Бухгалтерия приносит столько денег, сколько составляет разница между 10 договорами, которые заключает лично директор, и 100, которые может оформить и сопроводить пять бухгалтеров.

                                          Сколько прибыли Абрамовичу принесла его знаменитая яхта?

                                          Понятия не имею. Но она либо была развлечением, и тогда о прибыли говорить странно — это не бизнес, а просто хотелки человека, который хочет и может потратить деньги на что-то приятное, либо бизнесом — и тогда можно рассуждать о том, почему она была убыточная формально, и какую функцию она выполняла (возможно, она впечатляла потенциальных партнеров).

                                            –3
                                            Получается что уборщица приносит денег больше разработчика (давайте предположим что организация занимается разработкой ПО). Если равномерно распределить для простоты картины, получается 50% денег приносит уборщица. А вот бухгалтерия приносит денег где-то уже 90% — пусть договора будут примерно одинаковые опять же для простоты. Еще до разработчиков не добрались, а уже получается больше ста процентов. А ведь есть еще менеджмент, сейлзы, девопсы, QA. Вам не кажется что тут что-то не так? Вообще комментарий был не к тому, что уборщица или бухгалтерия не нужна. Смысл был в том, что крайне редко можно посчитать сколько приносит денег отдельный член трудового коллектива.
                                            это не бизнес, а просто хотелки человека, который хочет и может потратить деньги на что-то приятное

                                            Хотелки человека и в бизнесе имеют место быть. Захотелось, не знаю, зеркало в полный рост на ресепшене, взял и сделал. Не особо задумываясь о том, сколько именно оно принесет денег. Потому что есть внутренняя уверенность что это круто, привлекательно и вообще полезно. Есть ли вообще люди, которые высчитывали сколько прибыли принесет покупка того или иного офисного кресла? Да и есть ли способ это сделать? Думаю вы очень сильно упрощаете мотивацию людей.
                                              0
                                              Еще до разработчиков не добрались, а уже получается больше ста процентов. А ведь есть еще менеджмент, сейлзы, девопсы, QA. Вам не кажется что тут что-то не так?

                                              Нет, не кажется. Мы же говорим о том, сколько некий процесс отнимает от прибыли, а она меняется на каждом шаге. Отсутствие уборщицы уменьшит прибыль на 50%, отсутствие бухгалтерии уменьшит оставшуюся еще на 90.
                                              Ну, и никто не мешает отнимать больше 100 процентов — это означает, что задолго до достижения целевого -400% прибыль компании станет равна нулю. Уменьшалась бы и далее, но некуда.

                                              Смысл был в том, что крайне редко можно посчитать сколько приносит денег отдельный член трудового коллектива.

                                              Да нет, посчитать можно. Ценность, например, бухгалтера — это сэкономленное время основателя. Бизнес основателя в одно лицо приносит 1м рублей в месяц, при этом на бухгалтерскую работу он тратит 20%. После того, как он нанял бухгалтера — он тратит на это 2%. Бухгалтер стоит 100к. 1 000 000/100*(20-2)=180 000, значит приносит он 80к, причем неважно, ищет основатель компании в это свободное время новых клиентов или отдыхает — это уже вопрос того, куда эти 80к тратятся.
                                              Стоимость разрабов считается через проекты.
                                              Во всех крупных компаниях есть внутренняя валюта — человеко-часы средств производства, тобишь, разработчиков. Они считаются как зарплата+налоги+стоимость страховок/тренажерных залов+стоимость аренды места+амортизация оборудования+зарплата начальников. Это стоимость человека, то, во сколько он обходится компании. Дальше считаем часы, которые он тратит на проекты, и зная стоимость проектов, понимаем прибыль от человека. Стоит человек, к примеру, 22к/день, делает проект два месяца, проект стоит полтора миллиона. (1500000-(22000*20*2))/2=310к в месяц он заработал родной компании.

                                              Хотелки человека и в бизнесе имеют место быть. Захотелось, не знаю, зеркало в полный рост на ресепшене, взял и сделал. Не особо задумываясь о том, сколько именно оно принесет денег. Потому что есть внутренняя уверенность что это круто, привлекательно и вообще полезно.

                                              Вы путаете траты «на красоту» и «потому что захотелось» и целевые затраты, которые должны окупаться. Первое — это не бизнес, это просто утилизация «лишних» денег, которыми можно улучшать условия, а можно просто делать красиво. Есть у нас миллион денег на обустройство офиса — можно купить кресла, микроволновку и холодильник. Нет — значит, на старых креслах пусть сидят. Это в некоторых случаях имеет эффект, но проявляется он, по большему счету, только в крупных компаниях, когда люди осознанно хотят в Яндекс/Гугл, потому что у них офисы красивые, переговорки удобные, а на кухне бесплатные печеньки. Если вы компания с 10 сотрудниками и офисом на 40кв.м., то есть у вас микроволновка, нет у вас ее — всем пофигу, и на прибыль это не влияет: никто не придет к вам из-за ее наличия и никто не уйдет из-за отсутствия. Разве что сотрудники будут дольше на обед ходить. Поставить можно, но исключительно из-за удобства или внутренней уверенности что полезно, но окупаемости ждать бессмысленно — это не фактор, добавляющий ценности и не оборудование, приносящее прибыль. Ну, хоть 5 минут сотрудника каждый день, приносящего 200к стоят 2к, не факт, что он их потратит на работу.
                                              Но возможность поставить микроволновку она появляется исключительно потому, что она добавляет к CAPEX 10к и 20 рублей к OPEX, что в целом, на фоне CAPEX-а на офис в 1м и OPEX-a на него же в 50к немного несущественно.

                                              Однако, пытаясь потратить суммы, которые сравнимы с оборотом или прибылью, но не считая окупаемость для них, вы быстро прогорите и закроетесь нафиг. Если ИП с прибылью в 1м решит снять тратить на офис столько же, сколько условный Яндекс, то к нему, безусловно, придут пара человек, которым важен офис. Но вот только эти пара человек совсем не поднимут прибыль на стоимость офиса, и через месяц станет грустно, потому что офис стоит больше, чем вся его прибыль.
                                          0
                                          Да будет вам, уважаемый автор. Очевидно, что вы пытаетесь ненавязчиво уйти от обсуждения самого главного месаджа той статьи. Старый добрый вопрос по прежнему актуален. Кто из участников в условиях «быстрой проверки гипотез» сожжет себе мозги и здоровья, а кто присвоит себе львиную долю? Что больше ценится: раздача пинков или непосредственный вклад в производство продукта? Выгодно ли тем кто в роли раздатчиков пинков нанимать самостоятельных специалистов? Всё ли в порядке с системой «быстрой проверки гипотез»?

                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                          Самое читаемое